관측과 운용 — dig / 로그 / 흔한 오진 | 합동회사 코무라소프트

이전 장의 복습: 제 5 장에서는 DNSSEC 의 방어 범위와 last hop 문제, 그리고 다층 방어의 구성을 정리했습니다. 본 장에서는 그 방어를 「동작 중인 resolver 에서 무엇을 관측하면 무너짐을 알아챌 수 있는가」로 전개합니다. dig 의 기본 조작(DNS101 에서 다룬 범위)은 어디까지나 토대이며, 로그에서 poisoning 징후를 포착하는 패턴까지 들어갑니다.

관리 화면보다 먼저, 실제 응답을 본다

이름 해결 트러블에서는, 레코드 관리 화면의 스크린샷보다 먼저 "affected resolver 가 지금 무엇을 반환하고 있는지", "authoritative path 에서는 어떻게 보이는지" 를 비교하는 것이 지름길입니다.

$ dig @192.0.2.53 www.example.com A
$ dig +trace www.example.com A
$ dig +dnssec www.example.com A

여기서의 192.0.2.53 은 예시용 TEST-NET 주소입니다. 실제 확인에서는 자신이 관리하는 resolver 나 정당한 관측 대상만 사용합니다.

연습 6-1 — 최초의 분리 진단

관리 화면의 인상보다 먼저, 실제 응답을 비교합니다.

자주 있는 증상의 분리 진단

증상	먼저 의심할 것	최초의 확인
같은 resolver 를 쓰는 여러 사용자가 같은 오답	shared recursive cache	영향 resolver 와 authoritative path 의 비교
internal 에서만 다른 IP	split-horizon / 내부용 설계	설계 의도와 internal zone 의 유무
방금 만든 이름이 아직 NXDOMAIN	negative caching	부정 응답의 TTL
RRSIG / AD 가 얽힌 이상	DNSSEC validation / last hop	`dig +dnssec` 과 trust chain

negative caching 과 오진

"방금 만든 이름이 아직 없다", "internal 과 external 에서 다르다" 등은 poisoning 과 헷갈리기 쉬운 전형적인 예입니다. negative caching 과 split-horizon 을 먼저 제외하면 불필요한 오탐을 줄일 수 있습니다.

힌트: negative caching 의 TTL 은 SOA 의 minimum field 와 RFC 2308 에서 설명하는 동작으로 결정됩니다. 존재하지 않는 결과에도 수명이 있다는 것을 잊지 마세요.

연습 6-2 — negative caching 과 오진

poisoning 과 헷갈리기 쉬운 전형적인 예를 먼저 제외합니다.

Q4. 13:00:00 에 NXDOMAIN 이 300 초 동안 negative cache 되었습니다. 13:01:00 에 그 이름의 레코드를 생성했는데도, 13:02:00 에 아직 NXDOMAIN 입니다. 가장 가까운 설명은 어느 것입니까?

authoritative server 가 MX 밖에 반환하지 않기 때문에 negative caching 의 TTL 이 아직 남아 있기 때문에 DNSSEC 이 자동으로 무효화되었기 때문에 browser 의 favicon cache 이기 때문에

Q5. 다음 중 cache poisoning 보다 split-horizon / 내부용 설계를 의심할 단서로 가장 가까운 것은 어느 것입니까?

같은 shared resolver 에서 random label query 가 급증하고 있다 Additional 의 out-of-bailiwick data 를 무분별하게 수락하고 있는 로그가 있다 서명 검증 failure 가 연속되고 있다 사내 resolver 만이 내부 IP 를 반환하고, public authoritative 쪽은 의도대로 다른 답을 반환하고 있다

로그에서 이상을 포착하는 패턴

dig 로 개별 확인하는 것에 더해, resolver / 쿼리 로그를 정기적으로 보면 「지금 무언가가 일어나고 있다」「과거에 무언가가 일어났다」를 빨리 포착할 수 있습니다. 중급 코스의 관측으로는 다음 3 가지 패턴을 기억해 두면 현장에서 도움이 됩니다.

1. 동일 zone 에 대한 random label 집중

같은 부모 zone 에 대해 처음 보는 서브도메인에 대한 query 가 짧은 시간에 집중되고, NXDOMAIN 비율이 높다. fresh miss 를 의도적으로 만들어 attempts 를 축적하는 동작과 부합한다. querier IP 의 편중과 시간대의 집중도 함께 본다.

2. RRSIG 검증 failure 의 연속

동일 zone 에 대한 서명 검증 failure 가 짧은 시간에 연속되고 있을 때, (a) zone 측의 키 롤 / 서명 기한 만료, (b) 경로상에서의 응답 변조나 오수락, (c) 검증 측의 시각 어긋남, 의 3 축으로 분리 진단한다. clock 과 zone 의 운용 상황을 확인한 다음 남은 의심을 poisoning 이나 중간자로 추적한다.

3. NAT / port 관측의 악화

NetFlow / pcap 등으로 외향 UDP 의 source port 분포를 취해, 상정의 고 에페머럴대에서 좁은 연속 번호대로 축소되지 않았는지를 정기적으로 확인한다. NAT 구성 변경이나 middlebox 의 동작 변화를 빨리 포착할 수 있다.

연습 6-3 — 로그에서 이상을 포착하는 패턴

중급으로서 한 걸음 더 나아가, resolver / 쿼리 로그에서 poisoning 징후를 포착하는 관점을 확인합니다.

Q6. 어떤 zone 에 대해, 처음 보는 대량의 서브도메인에 대한 query 가 짧은 시간에 집중되고 있고, 게다가 각각 NXDOMAIN 을 반환하고 있습니다. cache poisoning 관점에서 가장 타당한 가설은 어느 것입니까?

사용자가 우연히 대량의 오타를 치고 있다 Kaminsky 형처럼 fresh miss 를 의도적으로 대량 발생시켜 attempts 를 축적하려는 동작의 징후일 수 있다 negative caching 이 오작동하고 있다 DNSSEC validation 이 성공한 증거

Q7. validating resolver 의 로그에서 「동일 zone 에 대한 RRSIG 검증 failure」가 짧은 시간에 연속되고 있습니다. 가장 먼저 분리 진단해야 할 가설의 조합으로 가장 적절한 것은 어느 것입니까?

브라우저의 cache 를 모두 삭제해야 한다 (1) zone 측의 키 롤오버 / 서명 만료, (2) 중간 경로에서의 변조나 잘못된 응답의 혼입, (3) 자신의 resolver 의 시각 어긋남 DS 레코드를 child 측에 두면 해결된다 TTL 을 0 으로 설정하면 검증이 통과한다

이 장에서 얻어갈 것

먼저 affected resolver 와 authoritative path 를 비교한다
+trace 는 delegation path 의 관찰에 적합하다
negative caching, split-horizon, browser cache 등의 오진 요인을 먼저 제외한다
로그에서는 「random label 집중」「RRSIG 검증 failure 연속」「port 분포의 축소」를 지속적으로 관측한다