VPN 없는 암호화 DNS는 질의를 숨길 뿐, 당신의 주소를 숨기지 않는다

집 네트워크가 보이는 DNS 유출 테스트는 암호화 DNS가 실패했다는 증거도 아니고, 무언가가 성공했다는 증거도 아니다. 그 테스트는 한 가지 질문에 답한다. 이 질의가 이 네트워크에서 어느 리졸버에 도달했는가. 그것이 문제인지는 무엇을 누구로부터 보호하려 했는지에 달려 있다.

어떤 테스트를 실행하기 전에 목표를 적어 두라.

1단계: 정말로 원하는 보호를 이름 붙이기

세 가지 목표가 섞여 있다. 경로 위의 관찰자가 질의 읽기를 멈추길 바랄 수 있다. 특정 리졸버가 질의를 받지 않길 바랄 수 있다.방문하는 웹사이트가 집 주소를 보지 못하게 하고 싶을 수 있다. 암호화 DNS는 첫째에 봉사하고, 둘째를 누가 충족하는지를 바꾸며, 셋째에는 아무것도 하지 않는다.

VPN은 셋째에 봉사하고, 제공자에 따라 첫째에도 봉사한다. 어느 도구도 다른 쪽의 상위 집합이 아니다.

2단계: 리졸버를 고르고 그 신원을 검증하기

DNS over TLS는 리졸버와의 TLS 세션으로 질의를 감싸고, DNS over HTTPS는 HTTP 요청으로 감싼다. RFC 7858과 RFC 8484가 둘 다를 설명하며 어느 쪽도 터널이 필요 없다. 운영상 중요한 것은 인증서가 설정한 이름에 대해 검증되는지다. 잘못된 상대와의 암호화 세션은 올바른 상대와의 평문보다 나쁘다. 즉 플랫폼이 제공하는 곳에서는 엄격 모드를 쓰고, 검증이 실패하면 물러나는 기회주의 모드는 쓰지 않는다. 설정을 믿기 전에 세션을 직접 확인하라:openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

핸드셰이크는 설정한 리졸버를 지목하고 검증할 수 있는 체인을 반환해야 한다.

3단계: 실패 시 동작 정하기

모든 구현에는 도달할 수 없는 암호화 리졸버에 대한 정책이 있고, 그 정책이 곧 프라이버시 결정이다. 엄격 모드는 조회를 실패시키며, 이는 눈에 띄고 짜증난다. 기회주의 모드는 평문으로 다시 시도하며, 이는 보이지 않고 중요한 바로 그날 목적을 무너뜨린다. 의도적으로 선택하고, 그 선택을 요구 사항 옆에 기록하라.

systemd-resolved에서는DNSOverTLS=yes을 쓰고opportunistic은 쓰지 않는다; Android에서는 자동이 아니라 Private DNS 호스트 이름 모드를 뜻한다.

실제로 무엇이 적용되는지는 다음으로 확인하라:resolvectl status | grep -i -A1 "dns over tls". 다시 로드된 적 없는 drop-in 파일은 아무것도 바꾸지 않기 때문이다.

4단계: 애플리케이션이 시스템 리졸버를 따르는지 확인하기

자체 보안 DNS 설정이 있는 브라우저는 시스템 구성을 완전히 우회하며, 내장 리졸버가 있는 컨테이너 런타임이나 하드코딩된 목록을 읽는 언어 런타임도 마찬가지다. 시스템을 따르게 하거나 명시적으로 구성하고 기록하라. 그다음 각각의 폴백 동작을 보라. 모두가 닫힌 실패를 하는 것은 아니다. 목록은 실제로 짧다. 브라우저, 컨테이너 런타임, 그리고 함께 실행하는 VPN 클라이언트다.

조직의 내부 이름은 승인된 내부 리졸버에 남는다. 테스트가 깔끔해 보이도록 이를 공용 서비스로 보내는 것은 의도적으로 다른 문제를 만든다.

5단계: 요구 사항에 비추어 유출 테스트 읽기

예기치 않은 리졸버를 보고하는 테스트는 단서이지 판결이 아니다. 의도한 암호화 리졸버, 앱별 설정, 또는 알지 못했던 평문 폴백을 관찰했을 수 있다. 보고된 리졸버를 2단계에서 구성한 것과 비교하고, 결과를 1단계의 목표와 비교하라.

목표가 질의를 로컬 네트워크에서 멀리 두는 것이었다면, 평소 리졸버를 보여 주는 테스트는 실제 발견이다. 목표가 탐색 중 익명성이었다면 어떤 DNS 설정도 그것을 제공하지 못했을 것이다.

수용 문구는 목표의 언어로 써라. 이 조회들은 이 조건에서 이 검증된 리졸버를 사용한다. 그보다 넓은 것은 검증할 수 없는 주장이다.