인증서는 갱신됐는데 브라우저는 옛것을 보여줬다 · 이름은 어디서 먼저 답하는가 · 퀴즈
퀴즈: 이름 해석 순서와 TTL
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
`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 으로 바꿔 두면 캐시가 되지 않으므로 그대로 옮긴다