아닙니다. DNSSEC은 DNS 데이터의 출처 인증을 보강해 응답이 서명된 영역의 데이터와 맞는지 검증하도록 돕습니다. DNS 질의나 응답 내용을 암호화해서 숨기는 기능은 아닙니다. DNS over HTTPS(DoH)는 DNS query-response를 HTTPS로 운반해 Client와 선택한 resolver 사이 TLS 전송에 기밀성과 무결성 보호를 적용합니다.
DoH를 사용해도 지정한 resolver는 질의를 처리하기 위해 내용을 받습니다. 따라서 DNSSEC의 데이터 진위 확인, DoH의 전송 보호, resolver를 신뢰하는 문제를 분리해야 합니다. 이 문서는 DNSSEC과 DoH가 함께 있어도 모든 관찰자에게 익명성을 주거나 질의를 종단 간 숨긴다고 주장하지 않습니다.
데이터의 출처와 전송 중 비밀성은 다른 성질입니다
DNSSEC(DNS Security Extensions)은 서명과 검증을 통해 DNS 데이터가 선언된 출처에서 왔는지 확인하는 방법을 제공합니다. RFC 9364는 DNSSEC의 목적을 DNS 데이터의 origin authentication이라고 설명합니다. 수신 측 검증기가 서명된 데이터를 확인할 수 있는 것이 핵심이며, DNS 질의 이름을 암호화해 숨기는 기능은 포함되지 않습니다. 따라서 ‘DNSSEC을 켰다’는 사실만으로 Wi-Fi 접근자나 경로상의 중간 장비가 질의 내용을 볼 수 없다고 답하면 안 됩니다.
DoH는 DNS query와 response를 HTTPS 교환으로 보냅니다. RFC 8484는 각 DNS query-response pair를 HTTP exchange로 매핑하고 TLS가 그 전송의 integrity와 confidentiality를 제공한다고 설명합니다. 이 보호는 Client와 설정된 DoH resolver 사이의 연결에 적용됩니다. resolver는 질의를 받아 응답해야 하므로 내용을 알 수 있습니다. 누가 그 resolver를 운영하는지, 접속 로그를 어떻게 다루는지, 다른 구간의 이름 해석을 어떻게 보호하는지는 별도 정책과 구현 문제입니다.
| 구성 | DNS 응답 출처 검증 | Client–resolver 전송 보호 | 질의를 받는 resolver의 관찰 |
|---|---|---|---|
| 일반 DNS, DNSSEC 검증 없음 | 해당 확인 없음 | DNS 메시지는 평문 전송일 수 있음 | 선택한 resolver가 질의 내용을 처리 |
| DNSSEC 검증, 일반 DNS 전송 | 서명이 있는 영역에서 데이터 origin을 검증 | 전송 내용 암호화는 제공하지 않음 | resolver와 전송 경로에서 질의가 보일 수 있음 |
| DoH, DNSSEC 검증 여부 별도 | DNSSEC validation 설정에 따라 별도 확인 | Client와 DoH resolver 사이 HTTPS/TLS 보호 | DoH resolver는 query를 받으며, 신뢰·기록 정책은 따로 검토 |
DNSSEC과 DoH를 각각 켜도 남는 관찰자를 찾습니다
가상의 노트북이 203.0.113.53에 일반 DNS 요청을 보냈고 해당 도메인은 서명되어 있으며 로컬 검증기가 DNSSEC 확인을 했다고 합시다. 응답 데이터의 출처를 검증해도 패킷 내용이 암호화되는 것은 아닙니다. 네트워크 경로를 관찰하는 장비는 요청 이름과 응답을 볼 수 있을 수 있습니다. DNSSEC은 위조·변조된 DNS 데이터가 검증을 통과하는 위험을 줄이는 목적이지, 누가 어떤 도메인을 조회했는지 감추는 목적이 아닙니다.
같은 Client가 HTTPS 기반 DoH resolver를 선택하면 DNS 메시지는 TLS 연결 안에 실립니다. 로컬 네트워크의 수동 관찰자는 그 TLS 보호 구간 안의 DNS 내용을 그대로 읽기 어렵지만, 접속 대상 resolver 주소와 연결 메타데이터까지 항상 감춰지는 것은 아닙니다. 그리고 resolver 자체는 query를 받아 처리하므로 질의 내용을 알 수 있습니다. DoH가 사용된다고 그 resolver가 자동으로 사용자의 익명성을 보장하거나 질의를 저장하지 않는다고 단정해서도 안 됩니다. 실제 보존 기간과 사용 범위는 해당 resolver의 공개 정책과 설정으로 확인해야 합니다.
다섯 가지 질문을 따로 답합니다
- 응답 데이터가 DNSSEC 서명 검증을 거쳤는지 확인합니다. 서명 없음·검증 실패·검증 불가를 각각 구분합니다.
- Client가 어떤 resolver를 사용하고 DNS 메시지가 일반 DNS인지 DoH인지 확인합니다.
- TLS가 보호하는 구간이 Client에서 선택 resolver까지인지 표시합니다.
- 그 resolver가 질의를 처리하는 주체임을 기록하고, 해당 업체의 신뢰·개인정보 처리 정책을 따로 확인합니다.
- 출처 인증과 전송 기밀성이 함께 있다고 질의가 모든 경로·종단에서 숨는다고 확장하지 않습니다.
두 기능은 함께 사용할 수 있지만 서로 대체하지 않습니다. DNSSEC은 resolver가 응답 데이터의 출처와 서명을 검증하도록 하고, DoH는 DNS 메시지를 HTTPS transport에 싣습니다. DoH 연결이라고 DNSSEC 검증이 자동으로 켜지는 것은 아니며, DNSSEC 검증이라고 평문 질의가 암호화되는 것도 아닙니다. 조직의 단말 설정과 resolver 정책에서 각각 확인해야 합니다. 네트워크 정책이 DNSSEC 서명 확인이나 DoH 사용을 허용·차단하는 방식도 구현에 따라 다릅니다.
암호화된 전송을 익명 통신으로 바꾸어 말하지 않습니다
대표적인 오해는 DNSSEC을 ‘DNS 암호화’라고 부르거나 DoH를 ‘누구도 질의 내용을 모르게 하는 기술’이라고 설명하는 것입니다. DNSSEC은 origin authentication에 초점을 둡니다. DoH는 TLS가 적용된 전송 구간에서 관찰자에게 메시지를 읽기 어렵게 하지만 지정한 resolver는 요청을 받습니다. 두 기술의 보호 지점과 신뢰 주체를 정확히 이름 붙이면 재귀 DNS, stub resolver, authoritative server의 역할을 혼동하는 일도 줄어듭니다.
관찰자가 어디에 있는지 기준으로 답을 완성합니다
회상 연습: 서명된 DNS 응답을 검증했지만 질의는 UDP 기반 일반 DNS로 전송됐습니다. 응답은 DNSSEC으로 데이터 출처를 확인할 수 있어도 질의 내용은 전송 중 노출될 수 있습니다. 이번에는 DoH를 사용하지만 검증기가 DNSSEC 데이터를 검증하지 않습니다. Client–resolver 구간은 TLS로 보호되지만 응답 출처 인증은 별도 확인이 필요합니다. 두 경우 모두 지정 resolver는 질의를 처리합니다. 이 결론은 직접 확인한 RFC 9364와 RFC 8484의 각 보호 범위에 한정됩니다. 예시는 직접 만든 교육자료이며 실제 기출 또는 집중 180제 카드가 아닙니다. 상품 구성은 /decks/security#focus-180에서 확인하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
서명된 DNS 답변을 검증했지만 평문 DNS로 질의했다. 다른 사례는 DoH를 쓰지만 DNSSEC 검증이 꺼져 있다. 각 경우 데이터 출처 인증, 전송 기밀성, resolver가 알 수 있는 내용을 나누어 답하라.
정답과 해설 확인
첫 사례는 검증된 서명 데이터의 출처를 확인해도 질의 전송이 암호화되지는 않는다. 둘째 사례는 Client–resolver TLS 구간의 DNS 메시지가 보호되지만 DNSSEC 응답 출처 검증은 별도이며, 두 경우 모두 resolver는 query를 처리한다.RFC 9364는 DNSSEC origin authentication을 설명하고 RFC 8484는 DNS query-response를 HTTPS로 운반하면서 TLS integrity/confidentiality를 제공하는 구간을 설명한다. TLS 보호는 선택 resolver를 질의 처리 주체에서 제외하지 않는다.