Quiz: resolution order and TTL

getent hosts www.lab.internal 은 10.0.0.99 를 주는데 dig www.lab.internal 은 10.0.0.10 을 준다. 가장 그럴듯한 이유는?

• dig 가 캐시된 옛 답을 돌려주고 있어서
• /etc/hosts 에 항목이 있고 nsswitch 가 files 를 dns 보다 먼저 보기 때문
• getent 가 IPv6 주소를 IPv4 로 잘못 보여 주기 때문
• 리졸버가 검색 도메인을 붙여 다른 이름을 조회했기 때문

TTL 3600 인 A 레코드를 새 주소로 바꿨다. 아무 준비 없이 바꿨을 때 최악의 경우 옛 주소가 돌아다니는 시간은?

• 새 레코드의 TTL 만큼
• 권한 서버가 세컨더리에 전달하는 refresh 간격만큼
• 리졸버가 다시 시작될 때까지 무기한
• 바꾸기 전 레코드의 TTL 인 3600초까지

존에 새 이름을 추가하기 전에 시험 삼아 조회해 봤더니, 추가한 뒤에도 한동안 NXDOMAIN 이 나온다. 이 시간을 정하는 것은?

• 존의 NS 레코드 TTL
• 새로 추가한 A 레코드의 TTL
• SOA 의 minimum 필드와 SOA 자체 TTL 중 작은 값
• 리졸버의 기본 설정값 300초

쿠버네티스 파드에서 api.example.com 을 조회하면 CoreDNS 로그에 api.example.com.default.svc.cluster.local 같은 질의가 먼저 보인다. 원인은?

• 파드의 resolv.conf 가 options ndots:5 와 검색 목록을 갖고 있어 점이 다섯 개 미만인 이름에 검색 도메인을 먼저 붙이기 때문
• CoreDNS 가 클러스터 밖 이름을 받으면 먼저 클러스터 도메인을 붙여 자기 존에서 찾아본 뒤 상류로 넘기기 때문
• 애플리케이션이 절대 이름 대신 상대 경로로 API 를 부르면 HTTP 클라이언트가 네임스페이스를 붙여 조회하기 때문
• kubelet 이 파드가 묻는 모든 외부 이름을 서비스 이름으로 오인해 서비스 도메인을 붙여 재작성하기 때문

캐시 리졸버에 api.lab.internal 의 A 를 물었더니 CNAME 줄과 www.lab.internal 의 A 줄이 함께 왔다. 이 답을 옳게 읽은 것은?

• 질의 타입을 잘못 지정해 서버가 두 종류의 레코드를 섞어 보낸 것이다
• CNAME 은 A 와 같은 TTL 을 강제로 공유하므로 둘 중 하나만 캐시된다
• 권한 서버가 존을 두 번 읽어 중복 응답을 만든 것이다
• 리졸버가 CNAME 사슬을 끝까지 따라가 별명과 최종 주소를 한 답에 넣은 것이며, 두 레코드의 TTL 은 따로 돈다

다음 주에 서비스를 다른 서버로 옮긴다. 숙련자가 지금 할 일로 가장 알맞은 것은?

• 이전 당일에 레코드를 바꾸면서 TTL 도 함께 낮춘다
• 미리 TTL 을 낮춰 두고, 이전이 끝난 뒤 TTL 을 되돌린다
• 리졸버들에 캐시를 비워 달라고 요청할 준비를 한다
• 레코드를 CNAME 으로 바꿔 두면 캐시가 되지 않으므로 그대로 옮긴다