도입 — DNS 캐시 포이즈닝이란 무엇인가
공용 리졸버가 거짓 RRset 을 기억하면, 이용자 전원이 같은 오답을 보는 구도를 파악한다.
가장 먼저 떠올릴 그림
| 등장 인물 | 역할 |
|---|---|
| 이용자 / browser | 이름을 조회하는 쪽. resolver 의 답을 믿는다. |
| shared recursive resolver | 여기에 cache 가 있다. 여러 이용자가 공유한다. |
| authoritative servers | 각 존의 정식 데이터를 보유한다. |
잘못된 RRset 이 shared recursive resolver 의 cache 에 남으면, 그 resolver 를 사용하는 이용자 전체에게 같은 오답이 배포됩니다.
DNS 캐시 포이즈닝은 「공용 기억의 변조」
DNS 에서 위험한 것은, 이용자의 단말 1 대만이 일시적으로 착각하는 것이 아니라 shared recursive resolver 가 거짓 RRset 을 기억해 버리고, 그것을 반복해서 재사용하는 것입니다. 이용자의 눈으로 보면 resolver 는 「답을 알고 있는 주체」로 보이지만, 그 답이 진짜인지 cache 인지는 보이지 않습니다.
그래서 troubleshooting 에서는 먼저 「지금 보이는 답은 authoritative 인가, cache 인가, 아니면 referral 의 도중인가」를 나누어 생각할 필요가 있습니다.
연습 1-1 — 우선 shared cache 를 주역으로 놓는다
권위 서버의 compromise 와 shared recursive resolver 의 poisoning 은 비슷해 보일 수 있습니다. 그러나 방어·관측에서 먼저 쫓아야 할 장소는 다릅니다.
Q1. DNS 캐시 포이즈닝에서 중심적으로 문제가 되는 상태는 어느 것입니까.
문제의 중심은 「공용 리졸버가 무엇을 기억해 버렸는가」입니다.
DNS 캐시 포이즈닝에서는 재귀 리졸버가 거짓 RRset 을 수락하여 cache 에 남기고, 그것을 이용자에게 재배포하는 것이 문제의 중심입니다. 권위 존 그 자체의 변조와는 구별해서 생각합니다.
Q2. 1 대의 공용 재귀 리졸버가 poison 되면 영향이 확산되기 쉬운 주된 이유는 어느 것입니까.
「1 대가 몇 명에게 돌려주는가」를 생각하면 정리하기 쉽습니다.
공용 재귀 리졸버는 많은 이용자에게 같은 cache 결과를 돌려줍니다. 따라서 1 대의 오수락이 같은 resolver 를 사용하는 이용자 전체로 파급되기 쉽습니다.
TTL 이 있기 때문에, 오답은 「한동안 남는다」
poisoned 된 RRset 은 수락된 순간에 영속화되는 것이 아니라, TTL 의 유효 기간 동안만 shared cache 에 남습니다. 따라서 patch 를 적용해도, 이미 남아 있는 cache entry 의 수명이 다할 때까지는 같은 오답이 보일 수 있습니다.
관측에서는 「잔여 TTL 이 비슷한가」「같은 resolver 를 사용하는 복수의 이용자에게서 같은 값이 보이는가」를 보면, browser 개별의 문제와의 구분이 쉬워집니다.
연습 1-2 — 오답은 TTL 동안만 남는다
poisoned 된 RRset 은 TTL 의 유효 기간 동안 shared cache 에 남습니다. 잔여 초 수를 따라갈 수 있으면 관측과 구분이 쉬워집니다.
Q3. 공용 리졸버가 09:00:00 에 TTL 300 초의 오답을 수락했습니다. 09:03:00 시점의 잔여 TTL 은 몇 초입니까.
09:00:00 부터 09:03:00 까지는 180 초 경과입니다.
300 초에서 경과 180 초를 빼므로, 잔여 TTL 은 120 초입니다. poisoning 이든 stale cache 든, 잔여 TTL 을 숫자로 따라갈 수 있는 것이 관측의 첫걸음입니다.
비슷해 보이는 현상을 혼동하지 않는다
internal DNS, split-horizon, negative caching, browser 의 HTTP cache 는 이용자의 눈으로 보면 「이름 해석이 이상하다」처럼 보일 수 있습니다. 그래서 「어느 계층의 cache 인가」를 먼저 고정하고, 그 다음으로 authoritative path 와 affected resolver 의 차이를 보는 것이 중요합니다.
split-horizon 이란: 같은 이름에 대해 사내용 resolver 와 사외(public) resolver 에서 의도적으로 다른 답을 돌려주는 DNS 의 운영 설계입니다. 예를 들어 사내에서는 내부 IP, 사외에서는 공개 IP 를 돌려주는 구성이 전형적입니다. 자세한 내용은 제 6 장에서 다루지만, Q4 의 선택지를 읽을 때는 이러한 「설계상의 차이」가 있을 수 있다는 점을 염두에 두세요.
연습 1-3 — 비슷해 보이는 현상을 혼동하지 않는다
internal DNS, split-horizon, negative caching, browser 의 HTTP cache 는 보이는 방식이 비슷할 수 있습니다. 먼저 「어느 계층의 cache 인가」를 고정합니다.
Q4. 「같은 사내 이름이 사내 resolver 와 public resolver 에서 다르게 보인다」는 상황으로 가장 있을 법한 설명은 어느 것입니까.
보이는 방식이 다를 뿐, 즉시 공격으로 단정할 수 있다고는 할 수 없습니다.
사내용과 사외용으로 다른 답을 돌려주는 split-horizon / internal DNS 는 평범하게 있습니다. 차이가 보였을 때는 먼저 설계 차이인지 이상인지를 구분합니다.
Q5. DNS 캐시 포이즈닝과 HTTP 캐시의 혼동을 피하기 위해 올바른 설명은 어느 것입니까.
DNS 의 TTL 과 HTTP 의 cache-control 은 다른 계층입니다.
DNS 캐시 포이즈닝은 이름 해석 결과의 공용 cache 가 문제이며, HTTP 나 CDN 의 cache 와는 따로 생각할 필요가 있습니다. DNS 의 TTL 을 변경해도 browser 의 HTTP cache 가 자동으로 지워지는 것은 아닙니다.
제 1 장의 정리
- DNS 캐시 포이즈닝은 shared recursive resolver 의 기억 이 주 무대
- 오답은 TTL 동안 남으므로, patch 와 cache 수명을 나누어 생각한다
- split-horizon 이나 HTTP cache 등, 보이는 방식이 비슷한 현상과 혼동하지 않는다