실제 시험 문제 20

이 글에서 익힐 것

• stub resolver, recursive resolver, authoritative server를 구분한다.

• DNS cache가 왜 필요한지 이해한다.

• DoH가 어느 통신 구간을 보호하는지 표시한다.

• transport security와 DNS data authenticity를 구분한다.

• DNSSEC가 cache poisoning 방어에 어떤 역할을 하는지 설명한다.

단계별로 따라가기

• Stub resolver

  사용자 PC/브라우저 쪽의 작은 DNS client. 보통 recursive resolver에게 질의를 맡긴다.

• Recursive resolver

  root, TLD, authoritative nameserver에 필요한 질의를 수행하고 최종 답을 client에게 돌려준다.

• Authoritative nameserver

  특정 domain zone의 공식 DNS record를 제공한다.

• Cache

  resolver가 TTL 동안 이전 답을 저장해 다음 질의를 빠르게 답하고 외부 질의를 줄인다.

정확한 의미 짚기

• 공격자는 resolver가 example.com을 질의하는 순간을 노려 위조 DNS response를 진짜 authoritative response보다 먼저 받아들이게 하려 한다.

• transaction ID, source port 등 응답 매칭 정보를 맞히거나 취약점·오설정을 악용한다.

• resolver가 거짓 A record를 cache하면 이후 여러 사용자가 공격자 IP로 연결될 수 있다.

• 핵심은 resolver가 거짓 데이터를 진짜 DNS 답으로 믿고 cache에 저장한다는 것이다.

정확한 의미 짚기

• DNS query와 response를 HTTPS 안에 넣어 client와 DoH resolver 사이에서 전송한다.

• 로컬 Wi-Fi 운영자나 단순 on-path 관찰자가 이 구간의 DNS 이름을 평문으로 읽거나 응답을 쉽게 바꾸기 어렵게 한다.

• TLS 인증서를 통해 client가 의도한 DoH resolver와 통신하는지 확인한다.

• 일반적으로 TCP port 443을 사용해 웹 트래픽과 섞인다.

정확한 의미 짚기

• DoH resolver가 거짓 정보를 가지고 있는지 암호학적으로 증명하지 않는다. 거짓 답도 TLS로 안전하게 전달될 수 있다.

• recursive resolver와 authoritative nameserver 사이의 모든 질의를 자동으로 DoH로 바꾸지 않는다.

• resolver 자체의 software 취약점, cache logic 오류, compromise를 해결하지 않는다.

• DNS zone owner가 서명한 data인지 client까지 검증하는 DNSSEC 기능을 대신하지 않는다.

• 선택한 DoH provider가 사용자의 DNS query를 보지 못하게 하지 않는다. provider는 질의를 처리하므로 볼 수 있다.

헷갈리는 개념 비교하기

• 보호 대상

  DNS transport channel

  DNS record의 origin authenticity와 integrity

• 대표 위협

  client-resolver 구간의 도청·변조

  위조 DNS data 수용/cache poisoning

• 기밀성

  해당 TLS 구간에서 제공

  제공하지 않음; record는 보통 공개

• 거짓 답 탐지

  resolver가 보낸 내용 자체가 참인지 보장하지 않음

  validating resolver가 signature chain을 검증해 위조 답을 거부 가능

헷갈리는 개념 비교하기

• 공격자가 카페 Wi-Fi에서 client의 평문 DNS 응답을 바꾸려 한다: DoH가 client↔resolver TLS 구간을 보호해 이 공격을 완화한다.

• 공격자가 recursive resolver의 upstream query에 위조 응답을 주입해 cache를 오염시킨다: client가 DoH를 써도 resolver가 이미 가진 거짓 답을 HTTPS로 받게 될 수 있다.

• resolver가 DNSSEC validation을 정확히 수행하고 zone이 서명돼 있다면 위조 record의 signature 검증이 실패해 cache 수용을 막을 수 있다.

문장을 하나씩 판별하기

• 문장은 DoH가 resolver에 대한 cache poisoning을 막는다고 일반화한다.

• DoH의 직접 보호는 transport이며 cache 내용의 권위 있는 서명 검증과 다르다.

• 특정 client-resolver on-path 변조를 막는 효과가 있어도 모든 resolver cache poisoning 방어라는 보편 명제는 성립하지 않는다.

• 따라서 Falsch다.

문제를 푸는 순서

1. 1단계: DoH=DNS over HTTPS라고 풀고 보호 구간을 그린다.

2. 2단계: cache poisoning의 대상은 resolver가 저장하는 DNS data임을 적는다.

3. 3단계: TLS channel 보호와 data origin validation이 다르다고 구분한다.

4. 4단계: DNSSEC validating resolver가 직접적인 위조 data 방어라고 덧붙인다.

5. 5단계: Falsch로 판정한다.

스스로 확인하기

• DoH가 직접 보호하는 두 endpoint는?

  DNS client/stub와 DoH recursive resolver.

• resolver cache의 record 진위를 암호학적으로 검증하는 기술은?

  DNSSEC validation.

• DoH provider가 사용자의 DNS query를 볼 수 있는가?

  그렇다. provider는 TLS endpoint이자 resolver이므로 질의를 처리한다.

설명의 근거

• Gedächtnisprotokoll Computersystemsicherheit WS2025_26.md, Networking / Multiple Choice, 4-(d).

• Vorlesung 08 Domain Name System — DoH/DoT와 DNSSEC 역할.

• Übung 5 Lösung — DNS cache poisoning과 방어.

이 문제가 어려운 이유

짧은 문제 문장 ‘DNS over HTTPS(DoH)는 Resolver에 대한 DNS-Cache-Poisoning-Angriff를 막는다. Wahr/Falsch?’ 안에 정의, 조건, 처리 순서가 압축되어 있습니다. 아래 예시에서는 이를 한 단계씩 펼쳐 확인합니다.