dig 를 읽는 순서

한 줄 요약

dig 출력은 위에서부터 읽는 게 아니라 status → flags → 각 섹션 순으로 읽는다. 이 순서를 지키면 응답 하나로 원인이 갈린다.

왜 이게 필요했나

"DNS 가 안 돼요" 라는 신고에는 최소 다섯 가지 서로 다른 상황이 섞여 있다. 이름이 아예 없는 것, 그 타입의 레코드만 없는 것, 리졸버가 답을 못 만드는 것, 서버가 답하기를 거부하는 것, 그리고 캐시가 낡은 것. 이 다섯은 대응이 전부 다르다. 그리고 dig 출력 한 번이면 다섯 중 어느 것인지 확정된다.

어떻게 동작하나

응답 코드부터 보자.

| status | ANSWER | 실제 의미 | 흔한 원인 | 다음에 할 일 |
| --- | --- | --- | --- | --- |
| NOERROR | 1개 이상 | 이름과 타입이 모두 존재 | 정상 | 다음 계층으로 |
| NOERROR | 0개 | 이름은 있으나 그 타입이 없음 | A 는 있고 AAAA 는 없음, CNAME 만 있고 대상 미생성 | 타입을 바꿔 재확인 |
| NXDOMAIN | — | 권한 서버가 그 이름 자체가 없다고 확정 | 오타, 미생성, search 도메인이 붙은 이름 | 권한 서버에 직접 질의 |
| SERVFAIL | — | 리졸버가 답을 못 만듦 | DNSSEC 검증 실패, 상위 무응답, 존 로드 실패 | 리졸버 로그 |
| REFUSED | — | 서버가 처리 의사 없음 | 재귀 미허용, ACL, 존을 갖고 있지 않음 | 질의 대상이 맞는지 |

NOERROR 인데 ANSWER: 0 인 경우가 가장 헷갈린다. 이름은 있는데 그 레코드 타입만 없는 것이다. IPv6 만 없거나, CNAME 은 걸었는데 대상 A 레코드를 안 만든 상황이 여기 해당한다.

그다음이 flags 다.

aa — 권한 있는 답. 이 글자가 없으면 캐시에서 온 답이다.
tc — 잘렸다. TCP 로 다시 물어야 한다.
rd / ra — 재귀 요청 / 재귀 가능
ad / cd — DNSSEC 검증 통과 / 검증 끄고 질의

목적별 조합을 손에 익혀 두면 좋다.

dig +short A example.com               # 값만dig +noall +answer example.com         # 답변 섹션만 (TTL·타입 포함)dig +noall +authority +additional example.comdig @1.1.1.1 example.com               # 특정 서버에 직접dig +norecurse @10.0.0.53 example.com  # 캐시에 있는지만 확인dig -x 8.8.8.8                         # 역방향dig -t MX example.comdig +tcp example.comdig +time=2 +tries=1 example.comdig +trace example.com                 # 루트부터 위임 추적

+trace 에는 함정이 있다. +trace 는 루트부터 각 단계를 직접 질의하므로 여러분의 리졸버를 우회한다. 그래서 "+trace 는 정상인데 애플리케이션은 실패" 가 흔하고, 그때 범인은 권한 서버가 아니라 리졸버 구간이다.

TTL 과 네거티브 캐싱

같은 질의를 리졸버에 반복하면 TTL 이 줄어드는 것이 보인다. 반면 권한 서버에 직접 물으면 항상 원래 설정값이 나온다. 이 차이가 "캐시에서 왔는지" 를 판별하는 가장 쉬운 방법이다.

없는 이름의 결과도 캐시된다. 네거티브 캐시 시간은 SOA 의 MINIMUM 필드와 SOA 레코드 자신의 TTL 중 작은 값이다. 그래서 레코드를 새로 만들었는데도 한동안 NXDOMAIN 이 계속되는 일이 생긴다. "만들었는데 왜 안 되냐" 의 정답이 대개 이것이다.

resolv.conf 의 숫자들

nameserver 10.0.0.2search prod.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5 timeout:2 attempts:3 rotate

nameserver 는 최대 3개까지만 쓰인다.
timeout 기본 5초(최대 30), attempts 기본 2회(최대 5). 첫 번째 네임서버가 죽어 있으면 사용자는 기본값 기준 5초를 그대로 체감한다. 타임아웃과 시도 횟수를 줄이지 않으면 이중화는 있으나 마나다.
ndots:n 은 "점이 n 개 미만이면 search 도메인을 먼저 붙여 본다" 는 규칙이다. 기본 1, 최대 15.

쿠버네티스의 ndots:5 는 유명한 함정이다. api.stripe.com 은 점이 2개라 5보다 작으므로, search 도메인 4개를 먼저 다 붙여 본 뒤에야 원래 이름을 묻는다. A/AAAA 쌍으로 세면 질의 10개 중 8개가 NXDOMAIN 을 받으려고 나간다. 다만 흔한 조언과 달리 ndots 를 1로 낮추면 클러스터가 깨진다 — payments.prod 같은 크로스 네임스페이스 호출이 전부 실패한다. 안전한 하한선은 2 다. 급할 때는 이름 끝에 점 하나를 붙여(api.stripe.com.) FQDN 임을 명시하면 search 를 건너뛴다.

현장에서 만나는 모습

UDP 53 만 열린 방화벽. 평소엔 아무 문제가 없다. 응답이 작으니까. 그런데 레코드가 늘거나 DNSSEC 서명이 붙어 응답이 512바이트를 넘는 순간 그 이름만 해석되지 않는다. "특정 도메인 하나만 안 된다" 는 신고의 원인이 여기인 경우가 있다. dig +notcp +bufsize=512 로 재현하고 ;; MSG SIZE rcvd: 를 본다.

캐시를 통째로 비우지 마라. rndc flush 는 시원하지만 그 뒤 몇 분간 상위 질의가 폭증한다. 문제가 된 이름만 rndc flushname api.example.com 으로 지우는 것이 정석이다.

다음 실습에서 할 것

dig 로 A/MX/NS/TXT 를 뽑고, TTL 이 줄어드는 것을 관찰하고, 역방향 조회를 하고, NXDOMAIN 응답에서 네거티브 캐시 시간을 계산한다. 마지막에는 hosts 항목을 넣어 getent 와 dig 의 답이 갈리는 것을 표로 제출한다.