종합 연습과 전체 복습
케이스 문제 8 문제로 bailiwick·entropy·NAT·DNSSEC·운용의 관점을 넘나들며 강좌를 마무리합니다.
여기서 마무리한다
이 장에서는 케이스 문제 8 문제를 통해 glue / entropy / NAT / AD bit / negative caching / split-horizon 을 횡단하며 풉니다. 장별 지식이 아니라, 여러 장을 조합한 관점에서 판단할 수 있는지를 확인합니다.
합격의 기준: 케이스 문제 8 문제 중 6 문제 이상 정답이면, cache poisoning 방어·관측에서 현장의 1차 분리 진단에 충분히 쓸 수 있는 상태입니다.
종합 연습에서 사용하는 관점
| 장 | 이 장에서 사용하는 관점 |
|---|---|
| 제 1 장 | "누구의 cache 에 누가 답을 넣었는가" 를 구분한다 |
| 제 2 장 | in-bailiwick glue 와 out-of-bailiwick additional 의 차이 |
| 제 3 장 | ID / source port / question / time window 의 일치와 entropy |
| 제 4 장 | 2008 년의 교훈과, patch / recursion control 의 단기 대책 |
| 제 5 장 | DNSSEC 의 방어 범위와 last-hop 의 trust 문제 |
| 제 6 장 | dig·로그·negative caching / split-horizon 의 분리 진단 |
종합 연습 7-1 — bailiwick · entropy · DNSSEC(구조 축)
referral 의 취급, port entropy, AD bit 와 last hop 등 「구조로 어디까지 지킬 수 있는가」를 케이스로 확인합니다.
Q1. 부모 존의 referral 에서 NS ns1.shop.example.com 과 A ns1.shop.example.com 192.0.2.53 이 함께 반환되었습니다. 가장 타당한 취급은 어느 것입니까?
이것은 자식 존으로 이동하기 위한 in-bailiwick glue 로서 한정적으로 사용하는 것이 타당합니다. shop.example.com 하위 임의 이름에 대한 일반적인 최종 answer 와 동일시하지는 않습니다.
Q2. referral 에 NS ns.partner.net 과 A ns.partner.net 198.51.100.10 이 Additional 로 따라왔습니다. 가장 안전한 판단은 어느 것입니까?
out-of-bailiwick 의 가능성을 의식하고, 필요하다면 ns.partner.net 자체를 별도로 해결하는 것이 안전합니다. referral 에 섞인 추가 데이터를 전면적으로 신뢰하는 것은 위험합니다.
Q3. resolver 가 NAT 하위에 있어, 외부로 나가는 source port 가 실질적으로 256 가지의 연속 번호로 축소되어 있습니다. 이때 가장 올바른 설명은 어느 것입니까?
port entropy 가 크게 감소하여 spoof 내성이 약해지기 쉽다는 설명이 가장 가깝습니다. source port randomization 은 "외부에서 보이는 다양성" 이 중요합니다.
Q4. stub resolver 가 AD=1 의 응답을 받았지만, 그 upstream recursive resolver 와 통신 경로도 충분히 신뢰하지 않습니다. 이때의 해석으로 가장 적절한 것은 어느 것입니까?
AD=1 은 유용한 힌트이지만, 그 recursive resolver 나 통신 경로를 충분히 신뢰하지 않는다면 만능의 엔드투엔드 증명으로 간주할 수는 없습니다. last hop 의 신뢰 문제를 잊지 않는 것이 중요합니다.
Q5. 대상 zone 이 unsigned 입니다. 가장 올바른 설명은 어느 것입니까?
unsigned zone 에서는 DNSSEC validation 만으로 지킬 수 없습니다. 그래서 query matching, entropy, glue hardening, recursion control 등 다른 hardening 도 계속 중요합니다.
종합 연습 7-2 — 운용·모니터링·종합 방침(운용 축)
모니터링 시그널, cache TTL 의 수명, 조직 방침까지 「현장에서 어떻게 운영하는가」를 확인합니다.
Q6. 어떤 zone 에 대해, 짧은 시간에 대량의 random 한 존재하지 않는 라벨에 대한 query 가 이어지고 있습니다. cache poisoning 관점에서 주의할 이유로 가장 가까운 것은 어느 것입니까?
random 한 존재하지 않는 라벨에 대한 query 가 늘어나면, uncached 한 질의 기회가 늘어나 miss 와 부하가 증가합니다. race 시도 횟수가 늘어날 수 있기 때문에, 모니터링상의 시그널이 됩니다.
Q7. patch 를 적용한 직후인데도, 같은 resolver 를 쓰는 사용자가 앞으로 2 분 정도 같은 오답을 볼 것으로 예상됩니다. 가장 직접적인 이유는 어느 것입니까?
이미 들어가 있는 cache entry 의 TTL 이 남아 있기 때문입니다. 소프트웨어를 고쳐도, 기존의 stale / poisoned data 의 수명이 남아 있다면 보이는 모습은 즉시 바뀌지 않습니다.
Q8. 조직의 recursive resolver 에 대한 종합 방침으로 가장 적절한 것은 어느 것입니까?
가장 적절한 것은, patch/update, ID/port entropy, glue/bailiwick hardening, trusted clients 에 대한 recursion 제한, DNSSEC validation, 모니터링을 조합하는 방침입니다. 단독의 설정에만 의존하지 않는 것이 중요합니다.
이 강좌의 도착점
- shared recursive resolver 의 cache 에 잘못된 RRset 이 남는다 는 것이 어떻게 사용자 전체에게 같은 오답이 배포되는 구도로 이어지는지 설명할 수 있다.
- referral / final answer / glue 를 구분하여, in-bailiwick / out-of-bailiwick 을 의식하며 다룰 수 있다.
- 응답 수락 조건(question / ID / address / port) 과, entropy 와 시도 횟수 의 관계를 식과 숫자로 파악할 수 있다.
- DNSSEC 의 origin authentication / integrity / authenticated denial of existence 와 confidentiality 가 별개라는 점을 설명할 수 있다.
- AD bit 의 의미를 last hop 의 trust 문제 와 함께 읽을 수 있다.
- 트러블 시에는 먼저
dig @resolver/dig +trace/dig +dnssec로 응답을 관찰하고, negative caching 이나 split-horizon 을 먼저 제외할 수 있다. - 최종적으로는 patch·entropy·bailiwick·DNSSEC·운용 모니터링 을 조합하여 생각할 수 있다.
정착을 돕기 위해 다음에 해 볼 것
- 자신이 관리하는 resolver 에서
dig +trace와dig +dnssec을 실행하여, referral 과 서명 검증의 출력을 눈으로 확인한다. - unsigned zone 과 signed zone 을 하나씩 골라
adflag 의 차이를 관찰한다. - negative caching 의 TTL 이 남아 있는 상황을 의도적으로 만들어, "만들었는데 보이지 않는다" 의 전형적인 패턴을 직접 체험한다.
- 운용 측에서는, random label 의 급증이나 서명 검증 failure 의 로그를 포착하는 모니터링이 있는지 확인한다.