자동화된 인증서 관리에서 systemd-resolved의 숨겨진 위험성
SSL/TLS 인증서의 자동화는 웹 보안 방식을 근본적으로 변화시켰습니다. Caddy 및 Let's Encrypt와 같은 도구들은 인증서를 획득하고 갱신하는 과정을 원활하게 만들었으며, 종종 수동 개입 없이 백그라운드에서 작동합니다. 하지만 이러한 원활함은 의존성을 만들어냅니다. 즉, 자동화 파이프라인은 건강하고 예측 가능한 DNS 확인 프로세스에 의존합니다. 이 프로세스가 선택적으로 실패할 경우, 단순히 인지되지 않을 뿐만 아니라 디버깅하기 어려운 치명적인 장애로 이어질 수 있습니다.
장애 모드: 선택적 DNS 장애
Caddy 서버의 인증서가 만료된 시나리오에서, 근본 원인은 로컬 애플리케이션에 네트워크 이름 확인을 제공하는 시스템 서비스인 systemd-resolved로 추적되었습니다. 장애는 모니터링 알림이 즉시 트리거될 만한 전체 블랙아웃이 아니라, 선택적인 장애였습니다.
선택적 장애는 시스템의 나머지 부분이 정상인 것처럼 보이게 만들기 때문에 특히 위험합니다. 서버는 외부 IP를 핑(ping)할 수 있고, 다른 서비스는 일부 도메인을 확인(resolve)할 수 있으며, 기본적인 연결성 확인은 통과할 수 있습니다. 그러나 ACME (Automated Certificate Management Environment) 챌린지—인증 기관(CA)이 도메인 소유권을 확인하는 프로세스—에 필요한 특정 DNS 쿼리가 실패합니다. 만약 ACME 클라이언트가 CA의 API 엔드포인트를 확인하지 못하거나 CA가 서버의 도메인을 확인하지 못하면, 갱신 프로세스는 백그라운드에서 조용히 실패합니다.
기술적 심층 분석: systemd-resolved 충돌
systemd-resolved에서 발생하는 흔한 장애 지점 중 하나는 서버의 호스트네임과 관련이 있습니다. 서버의 호스트네임이 요청된 도메인과 동일할 경우, 이름 확인이 실패하거나 예상치 못한 동작을 할 수 있는 알려진 이슈가 있습니다.
이 특정 버그를 완화하기 위해, 일부 관리자들은 서버가 호스트네임을 합성하려는 시도를 비활성화하는 재정의(override) 설정을 제안합니다:
Environment=SYSTEMD_RESOLVED_SYNTHESIZE_HOSTNAME=0
이를 /etc/systemd/system/systemd-resolved.service.d/override.conf의 서비스 재정의 파일에 추가함으로써, 관리자들은 systemd-resolved가 서버 자신의 이름을 로컬 주소로 확인하려는 시도를 방지할 수 있으며, 이는 ACME 챌린지 프로세스를 방해할 수 있습니다.
네트워킹 논쟁: systemd vs. 전문화된 도구
이 사건은 네트워킹 스택 내에서 systemd의 역할에에 대한 시스템 관리 커뮤니티 내의 더 넓은 논쟁을 조명합니다. systemd가 시스템 관리를 위한 포괄적인 도구 모음을 제공하는 것을 목표로 하지만, 그 범위가 서비스 관리를 넘어 전문적인 네트워킹 지식이 필요한 영역까지 확장되었다는 주장이 제기됩니다.
일부 숙련된 네트워킹 전문가들은 서버에서 systemd-resolved 및 systemd-networkd를 피하고 더 전문화되고 강력한 도구를 사용하는 것이 좋다고 주장합니다. 예를 들어, DNS 확인을 위해 unbound를 로컬에 설치하여 사용하는 것이 서버에 자주 권장됩니다. systemd-resolved와 달리, unbound는 검증, 재귀, 캐싱 DNS 리졸버로 설계되었으며, 고안정성 환경에서 더 예측 가능한 동작을 제공합니다.