DNSSEC과 다층 방어 — 무엇을 지키고 무엇이 남는가
DNSSEC의 방어 범위와 last-hop 의 한계를 파악하고, 다층 방어로 구성합니다.
이전 장의 복습: 제 4 장에서는 2008년의 교훈에서 단기 hardening(patch, entropy, recursion 제한, 모니터링)의 조합을 정리했습니다. 본 장에서는 한 걸음 더 나아가, DNSSEC 이 무엇을 지키고 무엇을 지키지 않는지, 그리고 「최후의 한 구간(last hop)」에 무엇이 남는지를 확인합니다.
DNSSEC 은 '서명으로 확인하는' 구조
DNSSEC 은 DNS data 에 서명을 붙이고, resolver 가 그 서명을 따라가며 검증할 수 있도록 하는 구조입니다. 중심에 있는 것은 origin authentication 과 integrity 이며, 통신 내용 그 자체의 비밀 유지가 아닙니다.
부모의 DS 에서 자식의 DNSKEY 로, 거기서 RRset 의 RRSIG 로 trust chain 을 따라갑니다.
제공하는 것 / 제공하지 않는 것
연습 5-1 — 무엇을 지키고 무엇을 지키지 않는가
'서명에 의한 검증'과 '비밀 유지'를 구분합니다.
Q1. DNSSEC 이 제공하는 것에 해당하지 않는 것은 무엇입니까.
DNSSEC 은 data origin authentication(데이터 원본 인증), data integrity(데이터 무결성), authenticated denial of existence(인증된 부재 증명) 를 제공하지만, confidentiality(질의 · 응답 내용의 비밀 유지) 는 제공하지 않습니다. 비밀 유지는 DoT / DoH 등 별도의 구조가 담당합니다.
Q2. DNSSEC 이 원칙적으로 제공하지 않는 것은 무엇입니까.
DNSSEC 은 서명에 의한 검증이 중심이며, query / response 내용 그 자체의 비밀 유지는 제공하지 않습니다. 비밀 유지가 필요하다면 별도의 통신 경로 보호나 설계를 고려해야 합니다.
Q3. DS 레코드의 역할로 가장 가까운 것은 무엇입니까.
DS 는 parent zone 쪽에 놓이며, child zone 의 DNSKEY 를 참조하기 위한 실마리가 됩니다. 이로써 trust chain 을 child 쪽으로 연결합니다.
secure / insecure / bogus 를 구분한다
signed zone 에서 검증이 통과하면 secure 입니다. 부모에 DS 가 없는 unsigned / insecure 한 zone 도 있습니다. 한편, 부모에 DS 가 있는데도 자식의 키나 서명을 따라갈 수 없을 때는 bogus 로 간주해야 합니다.
| 상태 | DS / 키 / 서명의 상황 | 의미 |
|---|---|---|
| secure | DS 있음, DNSKEY / RRSIG 의 검증도 통과 | 서명 검증이 성립한다 |
| insecure | 부모에 DS 가 없음 (unsigned zone) | DNSSEC의 보장은 없지만, 설계상의 상정 범위 내 |
| bogus | DS 는 있는데 검증이 통과하지 않음 | 변조나 설정 불비의 의심, 응답으로 사용해서는 안 된다 |
연습 5-2 — secure / insecure / bogus 를 구분한다
DS 의 유무와 DNSKEY / RRSIG 의 검증 결과로 상태가 결정됩니다.
Q4. parent 에 DS 가 있고, child 의 DNSKEY / RRSIG 의 검증이 통과하지 않을 때, validating resolver 는 그 zone 을 어떻게 다루는 것이 가장 가깝습니까.
parent 에 DS 가 있는데도 child 의 DNSKEY / RRSIG 검증이 통과하지 않는 경우, 그 zone 은 bogus 로 다루는 것이 가장 가까운 이해입니다. secure 도 insecure 도 아닙니다.
last hop 의 문제
recursive resolver 가 validation 을 하고 있더라도, stub 이 그 resolver 나 통신 경로를 충분히 신뢰할 수 있는지는 별개입니다. RFC 4033 은, security-aware stub resolver 가 DNSSEC의 혜택을 실제로 사용하려면 recursive server 와 channel 의 양쪽 모두를 신뢰해야 한다고 설명합니다.
따라서 AD bit 는 유용한 힌트이지만, 만능의 엔드투엔드 증명은 아닙니다.
이러한 환경에서는 stub 과 recursive 사이의 통신 경로를 별도로 보호하는 구조(DoT / DoH 또는 IPsec 경유의 신뢰할 수 있는 resolver 의 고정)와 조합해서 생각해야 합니다.
서명 검증을 실제 예로 본다 — dig +dnssec 의 출력
개념만으로는 잡기 어려우므로, 실제 dig 출력으로 확인합니다. signed zone(예: example.)에 +dnssec 을 붙여 질의하면, flags 에 ad 가 서고, RRSIG 레코드가 ANSWER 에 늘어섭니다.
$ dig +dnssec example. SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example. IN SOA
;; ANSWER SECTION:
example. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2024010101 7200 3600 1209600 3600
example. 3600 IN RRSIG SOA 8 1 3600 20260601000000 20260501000000 12345 example. AbCdEf...(서명 데이터)
여기서 주목할 것은 다음 2 가지입니다.
flags 에 ad 가 선다
RRSIG 가 늘어선다
반대로 bogus(DS 는 있는데 검증이 통과하지 않는) 상황에서는 status: SERVFAIL 이 되어 ANSWER 가 비게 됩니다. 「검증이 통과하지 않는 응답은 사용해서는 안 된다」를 구현이 체현하고 있는 예입니다.
다층 방어로 구성한다
DNSSEC 만으로도, query matching 이나 port entropy 만으로도, 단독으로는 충분하지 않습니다. 입구 (patch, recursion 제한), 일치 조건 (ID / port / question / bailiwick), 검증 (DNSSEC), 운용 (모니터링 · 로그) 를 겹쳐서 생각하는 것이 현실적입니다.
연습 5-3 — last hop 과 다층 방어
AD bit 와 다층 방어를, trust 의 경계를 의식하며 읽습니다.
Q5. stub resolver 에서 본 AD bit 에 대해 가장 적절한 설명은 무엇입니까.
AD bit 는 trusted 한 validating recursive resolver 와 그 통신 경로에 대한 trust 를 전제로 읽는 힌트입니다. stub 이 그 상대나 channel 을 신뢰할 수 없다면, AD=1 을 만능의 엔드투엔드 보장으로 볼 수는 없습니다.
Q6. modern resolver 의 방어 방법으로 가장 균형 잡힌 설명은 무엇입니까.
modern resolver 의 방어는 다층입니다. patch, query matching, ID/port entropy, glue hardening, recursion control, DNSSEC validation 등을 겹쳐서 생각하는 것이 현실적입니다.
이 장에서 얻어갈 것
- DNSSEC 은 origin authentication / integrity / authenticated denial of existence 를 제공한다
- confidentiality 는 별개의 문제이며, DNSSEC 만으로는 얻어지지 않는다
- AD bit 와 validating resolver 의 결과는, last hop 의 trust 문제와 함께 읽는다
- 단독의 구조에 의존하지 말고, patch · entropy · bailiwick · DNSSEC · 모니터링을 겹친다