Quiz: DNS Lookups in Practice

status: NOERROR 인데 ANSWER: 0 입니다. 무슨 뜻인가요?

• 이름 자체가 존재하지 않는다
• 이름은 존재하지만 요청한 레코드 타입이 없다
• 리졸버가 답을 만들지 못했다
• 서버가 재귀 질의를 거부했다

dig 응답 헤더의 flags 에 aa 가 없다면?

• 캐시(재귀 서버)에서 온 답이다
• DNSSEC 검증에 실패했다
• 응답이 잘렸다
• 재귀 질의가 거부됐다

레코드를 방금 만들었는데도 계속 NXDOMAIN 이 나옵니다. 원인으로 가장 유력한 것은?

• 레코드의 TTL 을 너무 길게 잡아 갱신이 늦어지고 있다
• 권한 서버를 재기동하지 않아 존 파일이 반영되지 않았다
• 네거티브 캐시에 남은 없음 응답이 아직 만료되지 않았다
• EDNS0 가 꺼져 있어 응답이 잘린 채 돌아오고 있다

dig +trace 는 정상인데 애플리케이션은 계속 실패합니다. 어디를 봐야 하나요?

• 권한 서버의 존 파일과 직렬 번호를 다시 확인한다
• 리졸버가 쓰는 루트 힌트 파일이 낡았는지 확인한다
• 응답이 커졌을 때의 TCP 폴백 설정을 점검한다
• 내 리졸버 구간 — +trace 는 루트부터 직접 물어 그 구간을 건너뛴다

쿠버네티스의 options ndots:5 를 1 로 낮추면 안 되는 이유는?

• payments.prod 처럼 점이 하나인 이름이 FQDN 으로 간주되어 해석에 실패한다
• kubelet 이 재기동되면서 파드가 한 번씩 다시 뜬다
• CoreDNS 가 search 도메인 목록을 통째로 무시하게 된다
• 노드의 conntrack 테이블이 금방 가득 차 버린다

특정 도메인 하나만 해석이 안 되고 나머지는 정상입니다. dig +notcp +bufsize=512 로 재현됐다면 원인은?

• 그 이름을 담당하는 권한 서버가 내려가 있다
• 네거티브 캐시가 남아 옛 결과를 계속 돌려준다
• search 도메인이 잘못돼 이름이 완성되지 않는다
• 응답이 512바이트를 넘는데 TCP 53 이 막혀 폴백하지 못한다

장애 대응 중 리졸버 캐시를 다루는 방법으로 권장되는 것은?

• 먼저 캐시 전체를 비워 확실하게 초기화한다
• 리졸버 프로세스를 재기동해 상태를 초기화한다
• 문제가 된 이름만 지운다(예: rndc flushname)
• 해당 존의 TTL 을 0 으로 바꿔 캐시를 무력화한다