표준 문서로 보는 DoT와 DoH
| 항목 | DoT | DoH |
|---|---|---|
| 표준 문서 | RFC 7858 (2016년 5월) | RFC 8484 (2018년 10월) |
| 상태 | Proposed Standard | Proposed Standard |
| 기본 포트 | 853 | 443(일반 HTTPS와 동일) |
| 전송 방식 | TLS 위에 DNS 메시지 | HTTP 요청·응답에 DNS 메시지를 담음 |
| 메시지 형식 | RFC 7858 참조 | 미디어 타입 application/dns-message |
| 주요 저자 소속 | USC/ISI, Verisign Labs, ICANN 등 | ICANN(Paul Hoffman), Mozilla(Patrick McManus) |
RFC 8484의 DoH는 하나의 DNS 질의와 응답을 하나의 HTTP 교환에 대응시킵니다. 서버는 GET과 POST를 모두 구현해야 하고, GET에서는 질의를 base64url로 인코딩해 dns 변수로 전달하며 POST에서는 DNS 메시지를 본문에 담습니다. HTTP/2 이상을 최소한으로 권장합니다. 구글 공개 DNS 문서도 https://dns.google/dns-query 가 RFC 8484를 따르며 GET과 POST를 지원하고, 별도의 JSON API는 GET만 지원한다고 설명합니다. RFC 7858은 DoT가 스텁 리졸버와 재귀 리졸버 사이 구간에 초점을 두며 포트 53을 DoT용으로 쓰면 안 된다고 규정합니다.
실제 도입에서 있었던 일
사례 1. 파이어폭스의 기본 활성화(2020)
위키백과(DNS over HTTPS) 기준으로 모질라는 2018년 클라우드플레어와 협력해 DoH를 ‘신뢰 재귀 리졸버’로 실험했고, 2020년 2월 25일부터 미국 이용자에게 파이어폭스의 DoH를 기본값으로 켜기 시작했습니다. 구글 크롬도 버전 83 이후 데스크톱에서 DoH를 지원합니다. 이용자가 따로 설정하지 않아도 보호가 적용된다는 장점이 있었지만, 기본으로 어느 사업자의 서버가 쓰이는지가 이용자에게 잘 보이지 않는다는 비판도 함께 따라왔습니다. 이 사례에서 알 수 있는 점은 ‘암호화’와 ‘신뢰할 수 있는 해석 서버 선택’이 별개의 문제라는 것입니다.
사례 2. 영국 ISP 협회의 ‘인터넷 악당’ 지명 논란(2019)
2019년 영국 인터넷 서비스 제공자 협회(ISPA)는 모질라의 DoH 계획을 이유로 모질라를 ‘인터넷 악당(Internet Villain)’ 후보로 지명했다가 커뮤니티의 반발 속에 지명을 철회했습니다. 모질라는 당분간 영국에서는 DoH를 기본값으로 켜지 않겠다고 밝혔습니다. ISP 입장에서는 DNS를 이용한 콘텐츠 필터링이 어려워진다는 우려가 있었습니다. 기술 표준 하나가 감시·필터링·프라이버시의 균형 문제로 번질 수 있음을 보여 주는 장면입니다.
사례 3. 기업 보안 관점의 경고(2021)
위키백과에 따르면 2021년 1월 미국 국가안보국(NSA)은 외부 DoH 리졸버가 기업 네트워크의 DNS 질의 필터링·검사·감사를 막는다는 이유로 기업에 주의를 당부했습니다. 같은 항목은 DoH가 보호자 관리 기능을 우회하는 데 쓰인 일이 있고, 2019년 악성코드 Godlua가 명령 서버 접속을 숨기는 데 DoH를 썼다고도 언급합니다. 암호화는 양쪽에 쓰일 수 있는 도구이고, 그래서 조직은 ‘사내 DNS 서버를 쓰는 DoH’처럼 통제 가능한 구성을 선택하기도 합니다.
내 환경에서 따져볼 점
- 브라우저 설정에서 보안 DNS(DoH)가 켜져 있는지, 켜져 있다면 어느 사업자를 쓰는지 확인합니다. 메뉴 이름과 위치는 브라우저와 버전마다 다릅니다.
- 안드로이드의 개인 DNS는 DoT 방식이며 호스트네임을 입력합니다. 입력한 서버를 신뢰할 수 있는지 먼저 판단하세요.
- 회사·학교 기기는 관리자 정책이 우선합니다. 임의로 바꾸면 사내 서비스 접속이 안 될 수 있으니 IT 부서 안내를 따르세요.
- 설정 뒤 일부 사이트나 사내 주소가 열리지 않으면 DNS 설정을 원래대로 되돌려 원인을 구분합니다.
흔한 오해와 정정
- 오해: DoH를 켜면 내 방문 기록이 완전히 숨겨진다. 실제: RFC 8484도 쿠키나 헤더, 연결 재사용 등으로 클라이언트를 식별할 수 있음을 지적합니다. 또 접속 대상 IP 등은 여전히 드러날 수 있습니다.
- 오해: DoH는 VPN과 같다. 실제: DoH는 DNS 질의만 암호화하고 이후 트래픽은 보호하지 않습니다.
- 오해: DoH가 DoT보다 항상 안전하다. 실제: 둘 다 TLS로 도청과 변조를 막는다는 목적은 같고, 차이는 포트와 운영 방식입니다.
한계와 논쟁
DNS 질의를 소수의 대형 사업자에게 모으는 것이 프라이버시에 좋은지는 의견이 갈립니다. 기존에는 ISP가 보던 정보를 다른 사업자가 보게 될 뿐이라는 시각도 있고, 반대로 사업자 정책이 더 엄격하다는 시각도 있습니다. 이 글은 사업자별 개인정보 정책을 비교하지 않았으며, 특정 서비스를 추천하지도 않습니다. 네트워크 환경의 영향(속도, 호환성)도 사용 환경마다 달라 일반론으로만 서술했습니다.
DNS 서버를 직접 바꾸고 싶다면
암호화 없이 공개 DNS 서버만 바꾸는 방법이 궁금하다면DNS 서버 변경하는 방법을 참고해보세요. 조회가 어떤 단계로 이루어지는지는DNS 조회 과정에서 확인할 수 있습니다.
DNS 레코드 타입이 궁금하다면
A, CNAME, MX 같은 DNS 레코드 타입 자체가 궁금하다면DNS 레코드 타입 완전정복도 확인해보세요. 암호화의 바탕이 되는TLS 핸드셰이크도 함께 읽어 볼 만합니다.
자주 묻는 질문
DoH를 켜면 인터넷 속도가 느려지나요?
암호화·복호화 과정이 추가되지만 현대 기기의 처리 속도로는 체감할 만한 지연은 거의 없습니다. 다만 이용하는 DoH 서버가 물리적으로 멀리 있다면 최초 연결 시 약간의 지연이 발생할 수 있습니다.
회사나 학교 네트워크에서 DoH를 쓰면 문제가 되나요?
회사나 학교가 특정 사이트를 DNS 차단 방식으로 제한하고 있다면, DoH를 사용하는 기기는 이 차단을 우회하게 될 수 있습니다. 이 때문에 일부 기관은 자체 네트워크에서 DoH 트래픽을 별도로 차단하거나 제한하는 정책을 적용하기도 합니다.
DoH와 DoT는 표준 문서가 따로 있나요?
네. DoT는 2016년 5월의 RFC 7858, DoH는 2018년 10월의 RFC 8484이며 둘 다 Proposed Standard 상태입니다.
DoH는 왜 443번 포트를 쓰나요?
RFC 8484는 DoH를 일반 HTTPS 트래픽과 섞어 보내면 경로상의 장비가 간섭하거나 트래픽을 분석하기 어려워진다고 설명합니다.
HTTP 쿠키는 DoH에서 문제가 되나요?
RFC 8484는 HTTP 쿠키 등이 클라이언트를 구분하는 단서가 될 수 있으므로, 특별한 사용 사례가 없다면 DoH 클라이언트가 쿠키를 받지 않아야 한다고 권고합니다.