내 ISP가 DNS를 가로채고 있었다

홈랩의 Podman 컨테이너에서 외부 사이트 접속이 실패해 조사한 결과, 일반 DNS 질의는 ISP 소유 IP 주소를 반환했지만 Cloudflare의 DoH 질의는 다른 주소를 반환함 Unbound 자체 호스팅만으로 DNS 변조를 막을 수는 없음. 직접 재귀 조회할 때 여러 네임서버와 주고받는 질의는 통상 평문이므로 ISP가 관찰하거나 변조할 수 있음 DNSSEC는 암호화가 아니라 서명 검증으로 DNS 데이터의 진위를 확인함. 유효한 서명과 신뢰 체인이 필요하며, 검증에 실패하면 잘못된 IP 대신 SERVFAIL을 반환함 DoH와 DoT는 리졸버까지의 전송 구간을 암호화하지만 리졸버 자체의 응답 조작까지 막지는 못함. ISP는 여전히 TLS 핸드셰이크의 SNI나 목적지 IP로 방문 사이트를 파악할 수 있음 현재 홈랩은 AdGuard와 dnscrypt-proxy 로 상위 DNS 질의를 암호화하며, DNS 장애를 피해야 하는 일부 컨테이너에는 Cloudflare를 대체 DNS로 설정함 접속 장애에서 발견한 DNS 가로채기 홈랩을 정비하던 중 Podman 컨테이너가 접근하려는 외부 사이트에서 거의 즉시 "Site cannot be reached" 오류가 발생함 DNS 문제를 의심해 dig로 Google DNS, Cloudflare 등 여러 제공자에 질의했지만 거의 모두 같은 IP 주소를 반환함 Cloudflare의 DoH 엔드포인트로 질의하자 전혀 다른 IP 주소가 나옴 일반 DNS 조회로 받은 주소의 소유자를 확인한 결과 ISP였으며, ISP가 질의를 가로채 변조한 주소를 반환하고 있음을 확인함 해결책으로 DoT(DNS over TLS) 또는 DoH(DNS over HTTPS) 를 떠올렸고, 경험을 공유한 뒤 나온 질문을 계기로 각 방식의 보호 범위와 한계를 정리함 Unbound를 직접 운영해도 전송 구간은 별개임 Unbound는 로컬에서 운영할 수 있는 DNS 리졸버로, 루트 네임서버부터 도메인의 권한 있는 네임서버까지 조회해 IP 주소를 찾음 DNS 조회는 단일 연결로 끝나지 않으며, 여러 네임서버에 보내는 질의는 전통적으로 평문 DNS, 주로 UDP를 사용함 이 구간에서 ISP가 DNS 트래픽을 관찰하거나 변조할 수 있어 자체 호스팅만으로 보호되지는 않음 Unbound의 forward-zone을 설정하면 직접 조회하는 대신 다른 리졸버로 질의를 전달할 수 있음 대상 리졸버가 DoT를 지원하면 해당 연결을 암호...