Karthikey Hegde, 홈랩서 일반 DNS와 DoH의 IP 응답 차이 보고
백엔드·시스템 엔지니어 Karthikey Hegde는 홈랩에서 일반 DNS 조회가 반환한 IP와 Cloudflare DoH 응답이 달랐고, 앞선 주소가 ISP 소유였다고 개인 블로그에 보고했습니다. 그는 Unbound의 평문 재귀 조회와 암호화된 상위 resolver 연결의 차이를 설명하고, 자신의 구성에서는 AdGuard와 dnscrypt-proxy를 연결해 상위 질의를 DNSCrypt로 보내며 일부 컨테이너에 Cloudflare를 대체 resolver로 둡니다.
본문
백엔드·시스템 엔지니어 Karthikey Hegde는 2026년 11월 3일 개인 블로그에 홈랩에서 ISP가 DNS 응답을 바꾼 것으로 판단한 경험을 적었습니다. Podman 컨테이너가 외부 사이트에 연결하지 못해 여러 DNS 제공자에 도메인을 조회했더니 거의 모두 같은 IP를 반환했고, Cloudflare의 DoH endpoint에서는 다른 IP가 나왔습니다. Hegde는 앞서 받은 주소의 소유 정보를 확인해 ISP 주소라고 판단했습니다. 글은 ISP 이름과 조회한 도메인을 밝히지 않아, 보고된 관측은 Hegde의 홈랩 사례에 한정됩니다.
Unbound는 집 안에서도 운영할 수 있는 DNS 재귀 resolver입니다. 답을 찾을 때 루트 네임서버에서 출발해 도메인의 권한 네임서버까지 필요한 서버들을 조회합니다. 이런 질의는 전통적으로 평문 DNS, 보통 UDP로 전송돼 ISP가 통신 경로에서 질의를 관측하거나 응답을 바꿀 수 있습니다. Unbound에 forward-zone을 설정하면 직접 여러 네임서버를 조회하는 대신 질의를 지정한 상위 DNS resolver로 전달합니다. 상위 연결에 DoT를 적용하면 Unbound와 그 resolver 사이의 질의가 TLS로 암호화됩니다. 로컬에 resolver를 둔다는 사실만으로 바깥 통신 경로까지 보호되는 것은 아니며, 상위 resolver 운영자는 질의를 처리하므로 이용자가 신뢰할 대상입니다.
DNSSEC은 전송 암호화와 다른 역할을 합니다. RFC 4033은 DNSSEC이 DNS 데이터에 전자서명을 붙여 데이터의 출처와 무결성을 확인한다고 설명합니다. 검증 resolver는 서명에 대응하는 공개 키를 신뢰하고, 키의 인증 체인을 미리 설정된 trust anchor까지 이어야 합니다. 도메인에 유효한 서명과 인증 체인이 없으면 DNSSEC으로 응답의 출처를 인증할 수 없습니다. DNSSEC은 질의와 응답이 오가는 통신 경로를 암호화하지 않으므로 ISP가 DNS 트래픽을 관측하는 일은 막지 않습니다. 변조된 응답이 DNSSEC 검증에 실패하면 resolver가 SERVFAIL을 반환할 수 있다고 Hegde는 설명합니다.
DoH와 DoT는 이용자와 선택한 DNS resolver 사이의 전송 내용을 암호화합니다. 이로써 ISP가 경로 중간에서 질의를 읽거나 응답을 바꾸기 어려워지지만, 질의를 받는 resolver 운영자에 대한 신뢰는 남습니다. 반면 DNSSEC은 서명된 DNS 데이터의 출처와 무결성을 검증합니다. 두 방식은 보호하는 대상이 다릅니다.
Hegde가 글에서 사용한다고 밝힌 구성은 AdGuard와 dnscrypt-proxy의 조합입니다. AdGuard가 로컬 DNS 역할을 하고, dnscrypt-proxy가 상위 DNS 질의를 DNSCrypt로 전달해 전송을 암호화합니다. Hegde는 컨테이너 업데이트 중 로컬 DNS가 멈추면 이에 의존하는 다른 컨테이너도 이름을 조회하지 못할 수 있어, 일부 컨테이너에 Cloudflare를 대체 resolver로 설정했다고 설명합니다. 이 컨테이너에서는 AdGuard가 우선 resolver이고 Cloudflare가 대체 경로입니다. 글은 Cloudflare 대체 경로의 전송 방식은 밝히지 않습니다.
자료: Karthikey Hegde의 개인 블로그 / 정리·해설: Trawling