DNS-over-HTTPS는 DNS 답이 만들어지는 방식은 거의 안 바꿨고, 질문을 누가 엿볼 수 있는지는 거의 다 바꿨다.

정치가 그렇게 뜨거워진 이유다.

프로토콜 수준에서 DoH(RFC 8484, 2018)는 신비로울 게 없다. 보통 UDP 53번 포트로 평문으로 오가던 DNS 쿼리를 443번 포트의 HTTPS로 감싼다. 반대편 리졸버 로직은 같다. 같은 레코드. 같은 질문. 다른 전송. 얼핏 소박해 보이지만, 얼마나 많은 네트워크 정책, 검열, 자녀 보호 필터, 기업 보안 검사, ISP 통계 수집이 그 평문 동작에 기대고 있었는지 떠올리면 얘기가 달라진다.

전송 방식 하나 바꿨는데, 거대한 논쟁이 났다.

전통 DNS가 드러낸 것

DNS는 1980년대에 프라이버시 고려 없이 설계됐다. 기기가 리졸버로 보내는 모든 쿼리가 평문으로 오간다. ISP는 내가 조회하는 모든 도메인을 본다. 네트워크 경로 위의 다른 누구도 — 회사 프록시, 카페 공유기, 정부 감시 시스템 — 마찬가지다.

설계 당시엔 문제가 아니었다. 네트워크는 작았고, 대부분 학계였고, 서로 협조적이었다. 엿듣는 사람을 염두에 두고 만든 물건이 아니었다.

2015년, IETF는 이 문제를 RFC 7626 DNS Privacy Considerations로 문서화했다. 그 무렵 평문 DNS는 인터넷에서 가장 손쉬운 수동 감시 채널이 돼 있었다. ISP는 DNS 데이터를 광고, 분석, 콘텐츠 삽입에 썼다. 정부 검열 시스템은 DNS로 걸렀다. 회사 프록시는 규정 준수를 이유로 DNS를 기록했다. 그리고 공유 네트워크에서 패킷만 떠 보면 누가 어느 사이트에 가는지 그대로 보였다.

DoH가 바꾸는 것

DoH는 DNS 쿼리를 HTTPS 안에 넣어 암호화한다. 쿼리는 443번 포트로, 일반 웹 트래픽에 섞여 오간다. 경로 위의 관찰자는 리졸버(Cloudflare 1.1.1.1이나 Google 8.8.8.8 같은)로 가는 HTTPS 연결은 보지만, 어떤 도메인을 묻는지는 못 본다.

ISP는 여전히 내가 리졸버에 접속한다는 건 본다. 그 뒤에 접속하는 IP 주소도 본다. IP에서 도메인을 짐작할 수 있을 때도 있다(특히 전용 IP를 쓰는 사이트). 하지만 DNS 질문 자체 — “example.com의 IP가 뭐지?” — 는 가려진다.

보통 사용자에게 이건 가장 뻔한 수동 감시 채널을 닫는 일이다. ISP가 내가 방문한 모든 도메인의 목록을 만드는 일이 공짜에서 비싼 일로 바뀐다.

DoH vs DoT: 정치적 차이

DNS-over-TLS(DoT, RFC 7858, 2016)도 같은 일을 한다 — DNS 쿼리를 암호화한다. 다만 전용 포트 853번을 쓴다. 암호화 수준은 같다. 프라이버시 개선도 같다.

정치적 차이는 이거다. 853번 포트는 알아보기도, 막기도 쉽다. 암호화된 DNS를 막고 싶은 네트워크 운영자는 853번만 막으면 된다. 443번 포트의 DoH는 안 보인다 — 평범한 HTTPS 트래픽처럼 보인다. 443번을 막으면 웹 전체를 막는 셈이다.

그래서 DoH가 DoT보다 논쟁적이다. DoT는 네트워크 운영자에게 선택권을 준다. 암호화된 DNS를 허용할지 막을지. DoH는 그 선택권을 빼앗는다. HTTPS를 막지 않고는 DoH를 막을 수 없다.

ISP가 싫어한다. 기업 IT가 싫어한다. DNS로 검열하는 정부가 싫어한다. 반대 논리는 하나로 모였다. “우리 네트워크에서 DNS를 보고 통제할 능력을 빼앗는 것이다.”

맞다. 그게 요점이다.

반발은 진짜였다

Mozilla가 Firefox에서 DoH를 기본으로 켜겠다고 발표했을 때(처음엔 모든 DNS를 Cloudflare로 보냈다) 반발이 거셌다.

ISP는 네트워크 관리, 남용 방지, 법원 명령 이행을 위해 DNS가 보여야 한다고 주장했다. 2019년 영국 인터넷서비스제공자협회(ISPA)는 DoH가 ISP 수준 필터와 자녀 보호 기능을 우회한다며 Mozilla를 ‘인터넷 악당(Internet Villain)’ 상 후보에 올렸다가, 역풍을 맞고 후보 지명은 물론 그 부문 자체를 없앴다.

기업 IT는 DoH가 내부 DNS 정책을 우회한다고 주장했다. 회사 노트북이 시스템 리졸버를 쓰면 회사가 DNS를 통제한다 — 악성 도메인을 막고, 사용 정책을 적용하고, 내부 도메인을 제대로 연결한다. Firefox가 DNS를 Cloudflare로 직접 보내면 그게 전부 깨진다.

정부는 DNS 기반 차단에는 정당한 이유(아동 성착취물, 테러 콘텐츠, 법원 명령)가 있고 DoH가 그 수단을 무력화한다고 주장했다.

어느 주장도 완전히 틀리진 않았다. 다만 평문 DNS는 감시 채널이고 사람들에게 쿼리를 암호화할 선택지가 있어야 한다는, 똑같이 타당한 주장과 부딪칠 뿐이다.

DNSSEC와의 혼동

DoH와 DNSSEC는 서로 다른 문제를 푸는데도 끊임없이 혼동된다.

DoH는 프라이버시를 준다 — 누가 질문을 볼 수 있는가. 전송을 암호화해서 관찰자가 DNS 질문을 못 읽게 한다.

DNSSEC는 무결성을 준다 — 답이 진짜인가. DNS 응답에 서명해서 변조되지 않았는지 검증할 수 있게 한다.

DNSSEC 없는 DoH는 암호화된 거짓말을 줄 수 있다. 질문은 감춰졌지만 답은 위조됐을 수 있다. DoH 없는 DNSSEC는 경로 위의 모두가 볼 수 있는, 진짜임이 확인된 답을 준다.

둘 다 있어야 한다. 대부분은 둘 다 없다. DoH는 브라우저 기본값을 타고 퍼졌다. DNSSEC는 여전히 대부분의 도메인에 없다 — .com의 압도적 다수가 서명되지 않은 상태다. 서로가 필요한 두 기술이 완전히 다른 속도로 깔리고 있다.

실제로 바뀐 것

기술 변화는 브라우저 기본값으로 들어왔다. Firefox는 미국과 캐나다(2022년부터는 러시아와 우크라이나도)의 데스크톱 사용자에게 DoH를 기본으로 켠다. DoH가 실패하면 시스템 리졸버로 돌아가는 폴백 모드다. Chrome은 시스템 리졸버를 따른다 — 설정된 리졸버가 DoH를 지원하면 Chrome이 알아서 DoH로 올려 쓴다.

실제 효과: 수많은 사용자가 자기도 모르게 DNS를 암호화하고 있다. 그 사용자들에 대해서는 ISP 수준의 DNS 감시가 훨씬 어려워졌다.

회사 네트워크의 사용자라면, 기업 IT가 여러 방법(카나리 도메인, 그룹 정책, 네트워크 단에서 리졸버 강제)으로 DoH를 감지하고 끌 수 있다. 우회가 완벽하지는 않다.

DNS로 검열하는 나라의 사용자에게 DoH는 우회 수단이 된다 — DoH 리졸버 자체가 막히지 않았다면. 그리고 검열하는 쪽은 잘 알려진 리졸버를 IP 주소와 호스트명으로 막을 수 있다. 쫓고 쫓기는 싸움은 계속된다.

직접 켜고 싶다면, 프로젝트가 아니라 설정 하나다. Chrome: 설정 → 개인정보 보호 및 보안 → 보안 → 보안 DNS 사용. Firefox: 설정 → 개인 정보 및 보안 → DNS over HTTPS, 여기서 ‘최대 보호’를 고르면 평문으로 돌아가지 않는다. Windows 11은 네트워크 어댑터의 DNS 설정에서 알려진 리졸버에 대해 시스템 전체 DoH를 쓸 수 있다. 안드로이드의 ‘비공개 DNS(Private DNS)‘는 DoH가 아니라 DoT를 바탕으로 만들어졌다 — 같은 생각, 다른 포트다.

불완전한 그림

DoH가 DNS 질문을 암호화했다. 좋다. 하지만 TLS 핸드셰이크의 SNI가 아직 목적지를 흘린다. 질문은 숨기고, 다음 패킷에서 답을 발표한 셈이다.

ECH(Encrypted Client Hello)가 그 구멍을 막는다 — 2026년 3월 RFC 9849가 됐고, Chrome과 Firefox는 이미 지원한다 — 다만 서버 쪽에서 켠 경우에만 작동하고, 지금은 주로 몇몇 대형 CDN 뒤에 있는 사이트들이다. 그게 보편화되기 전까지 DoH의 프라이버시 개선은 진짜지만 반쪽이다. 어떤 도메인을 찾는지는 숨겼다. 어떤 도메인에 접속하는지는 여전히 드러난다.

완전한 프라이버시 스택 — 질문 암호화에 DoH, 답 무결성에 DNSSEC, 목적지 보호에 ECH — 은 표준 문서로는 다 있다. 실제로는 대부분의 연결이 그중 하나라도 있으면 다행이다.

쉬운 부분부터 풀었다. 어려운 부분은 더 오래 걸리고 있다. 늘 그렇듯.