Summary

  • APNIC에 실린 실험에서 Geoff Huston은 캐시가 빈 BIND 9.20.23으로 www.potaroo.net을 찾았다. 루트에서 최종 주소까지 질의는 네 번이었다.
  • teams.microsoft.com은 Huston의 BIND 9.20 추적에서 94번을 요구했다. 같은 글에 실린 9.16의 247번과 9.21의 29번은 조건이 다른 관찰이다. 버전별 속도 순위가 아니라 의존 관계를 읽는 자료다.

따뜻한 캐시는 도메인 설계의 어려운 부분을 지운다. 처음 길을 찾을 때 만난 갈림길을 기억해 두고 다음 사람에게는 곧장 답을 준다. APNIC 수석과학자 Huston은 그 편의를 없앴다. 로컬 BIND가 www.potaroo.net을 찾을 때 루트, .net, potaroo.net의 서버, 최종 주소를 차례로 물었다. 네 번이면 손가락으로 셀 수 있다.

다른 이름은 손가락이 모자랐다. Huston의 원문에는 Ondřej Surý가 BIND 9.16으로 teams.microsoft.com을 찾으며 기록한 247번, Huston이 9.20에서 본 94번, Surý가 9.21에서 본 29번이 나란히 나온다. 실험 조건이 같지 않으므로 업그레이드 성능을 이 숫자로 계산할 수 없다. 중요한 사실은 하나의 화면상 이름이 여러 이름 찾기를 연쇄적으로 부른다는 점이다.

이 사례에서 CNAME 네 개는 리졸버를 새 이름으로 계속 보낸다. 이미 알아낸 위임 정보를 이용하는 구간도 있지만 .net으로 돌아가는 구간도 있다. 네임서버 이름을 알아냈다고 그 서버에 보낼 IP 주소까지 안 것은 아니다. 위임받은 영역 안의 서버라면 glue 레코드가 주소를 함께 줄 수 있다. 서버 이름을 여러 도메인과 최상위 도메인에 흩어 놓으면 본래 목표에 닿기 전에 서버 주소부터 더 찾아야 한다.

DNSSEC 검증에는 키 조회도 따른다. 리졸버가 장애에 대비해 후보 서버를 미리 더 알아둘 수도 있다. 그 선택은 정상적인 첫 질의에 비용을 보태는 대신 실패했을 때 쓸 길을 남긴다. 별칭과 위임은 도메인 운영자가 정하지만 첫 방문의 일을 하는 것은 세계 곳곳의 독립된 리졸버다.

Huston의 추적만으로 장애나 전 세계 지연을 주장할 수는 없다. 실제 운영 영향을 말하려면 같은 설정에서 경과 시간과 장애 시 동작을 측정해야 한다. 그래도 도메인 설계 회의에 던질 질문은 충분히 생겼다. 설정 한 줄이 편해질 때, 처음 찾아오는 리졸버에게는 몇 번의 문 두드리기가 추가되는가?