한 개발자가 주말에 홈랩 문제를 손보던 중 뜻밖의 사실을 발견했다. 자신의 Podman 컨테이너가 외부 사이트에 접속하지 못하고 "사이트에 연결할 수 없음" 오류를 거의 즉시 뱉어냈던 것이다. DNS 설정을 의심한 그는 여러 공개 DNS 제공업체로 dig를 돌려봤다. 구글 DNS, 클라우드플레어 등 대부분이 동일한 IP를 돌려줬지만, 유독 클라우드플레어의 DoH(DNS over HTTPS) 엔드포인트만 전혀 다른 IP를 반환했다. 처음 받은 IP의 소유자를 추적해 보니, 다름 아닌 자신이 쓰는 ISP였다. ISP가 평문 DNS 응답을 가로채 가짜 IP를 끼워 넣고 있었던 것이다.
이 경험담은 소셜 미디어에서 화제가 됐고, 그 과정에서 저자는 암호화 DNS와 DNSSEC을 둘러싼 흔한 오해들을 마주했다. 이 글은 그 오해를 하나씩 짚으면서, 결국 어떤 구성을 실제로 운영하게 됐는지 정리한 기록이다. 한국의 실무자에게도 이 주제는 남 일이 아니다. DNS 변조는 특정 사이트 차단이나 광고 삽입 등의 목적으로 통신사 단에서 충분히 일어날 수 있는 일이기 때문이다.
왜 평문 DNS가 문제인가
문제의 뿌리는 전통적인 DNS 해석 과정이 평문, 그것도 대개 UDP로 오간다는 데 있다. 로컬에서 Unbound 같은 리졸버를 직접 돌린다고 해도 사정은 비슷하다. Unbound는 클라우드플레어의 1.1.1.1이 하는 일을 로컬에서 수행하는 리졸버로, 루트 네임서버부터 시작해 도메인의 권한 네임서버까지 차례로 질의하며 IP를 알아낸다. 그런데 이 해석은 단일 연결로 끝나지 않고 여러 네임서버와 평문으로 주고받는 과정을 거친다. 바로 이 지점에서 ISP가 트래픽을 엿보거나 변조할 여지가 생긴다.
Unbound에는 forward-zone을 설정하는 방법이 있다. 직접 재귀 해석을 하는 대신 질의를 다른 리졸버로 넘기는 것이다. 이때 넘겨받는 리졸버가 DoT(DNS over TLS)를 지원하면 그 구간의 연결이 암호화되어, ISP가 중간에서 손쉽게 들여다보거나 조작하기 어려워진다. 저자가 처음 떠올린 해법도 바로 DoT나 DoH였다.
DNSSEC은 암호화가 아니라 검증이다
많은 이들이 DNSSEC이 이 문제를 막아준다고 생각한다. 이름에 'DNS'와 'Security'가 들어 있으니 그럴 법도 하다. 하지만 DNSSEC은 암호화가 아니라 검증으로 작동한다. 트래픽을 암호화해 보내는 것이 아니라, 암호화 서명을 통해 DNS 데이터가 진짜이고 변조되지 않았음을 확인하는 방식이다. 따라서 전송 구간의 트래픽은 여전히 평문이고, ISP는 그대로 엿볼 수 있다. 다만 변조된 응답이 DNSSEC 검증에 실패하면 리졸버가 가짜 IP 대신 SERVFAIL을 돌려주므로, 결과적으로 변조된 주소를 받아들이지는 않게 된다.
문제는 적용 범위다. DNSSEC 검증이 작동하려면 질의 대상 도메인 쪽에 유효한 서명과 신뢰 체인이 제대로 구성돼 있어야 한다. 그런데 2026년 10월 Defaults.Exposed 조사에 따르면 평가 대상 도메인 가운데 완전히 검증되는 DNSSEC 체인을 갖춘 비율은 7.03%에 불과하다. 즉 DNSSEC은 변조 탐지에는 의미가 있지만, 전체 도메인의 극히 일부에만 걸려 있어 보편적 방어책으로 삼기는 어렵다.
암호화 DNS의 한계와 실제 구성
DoT와 DoH 역시 만능은 아니다. 이들은 질의를 보내는 리졸버와의 연결을 암호화할 뿐, 그 리졸버 운영 주체 자체가 응답을 조작하지 않는다는 보장은 없다. 결국 신뢰의 대상이 ISP에서 리졸버 운영자로 옮겨갈 뿐이다. 또한 일반 웹 트래픽이 TLS로 암호화돼 있어도, ISP는 TLS 핸드셰이크의 SNI에서 호스트명을 볼 수 있고 때로는 목적지 IP만으로도 접속 사이트를 추정할 수 있다. 이를 가리려면 VPN으로 트래픽을 터널링해야 하는데, 저자는 Tailscale의 exit node 기능을 통해 Mullvad를 사용한다. 물론 이 역시 신뢰의 일부를 VPN 제공자에게 넘기는 선택이다.
저자가 최종적으로 운영하는 구성은 이렇다. 3년 넘게 써온 Pi-hole/AdGuard 계열에서 지금은 AdGuard를 DNS로 두고, 상단 질의는 dnscrypt-proxy가 DNSCrypt로 암호화해 처리한다. 다만 모든 컨테이너를 로컬 DNS로만 보내지는 않는다. 컨테이너를 업데이트하다가 로컬 DNS 서버가 죽으면 그에 의존하는 다른 컨테이너의 이름 해석까지 함께 멈추기 때문이다. 그래서 DNS 장애를 감내할 수 없는 컨테이너에는 클라우드플레어를 폴백으로 두되, 평상시 기본 DNS는 여전히 로컬 AdGuard가 담당하도록 했다. 서버는 NixOS로 운영하며 관련 dotfiles는 오픈소스로 공개돼 있다.
이 사례가 주는 실무적 교훈은 분명하다. DoT·DoH·DNSSEC은 각기 다른 위협에 대응하는 서로 다른 도구이며, 암호화냐 검증이냐를 혼동하면 실제로 막으려던 문제를 못 막는다. 전송 구간 변조가 걱정이라면 암호화(DoT/DoH/DNSCrypt)가, 응답 위조 탐지가 목적이라면 DNSSEC이 각각의 역할을 한다. 그리고 가용성을 고려하면 로컬 리졸버 단일 의존은 위험하므로 폴백 경로를 함께 설계하는 편이 현실적이다.