느린 DNS 확인 문제 해결하기

DNS 확인은 눈에 띄지 않을 만큼 빨라야 합니다. 캐시된 응답은 보통 한 자릿수에서 두 자릿수 초반 밀리초이고, 캐시되지 않은 전체 조회도 수백 밀리초를 넘는 경우는 드뭅니다. 이보다 눈에 띄게 느리다면 막연하고 전반적인 느림이 아니라 소수의 구체적인 원인 중 하나인 경우가 대부분입니다.

흔한 원인

• 잘못 구성되었거나 과부하 상태인 리졸버: ISP의 기본 리졸버 상태가 나빠지는 일은 사람들이 생각하는 것보다 흔하며, 1.1.1.1이나 8.8.8.8 같은 공용 대안으로 바꿔 보는 것은 단순한 임시방편이 아니라 정당한 진단 단계입니다.
• 긴 CNAME 체인: 리졸버가 실제 A/AAAA 레코드에 도달하기 전에 따라가야 하는 홉마다 지연이 추가되며, 네다섯 홉의 체인이라면 누적되는 지연이 상당합니다.
• 빠른 캐시 응답 대신 잦은 전체 조회를 유발하는 매우 짧은 TTL: 빠른 전파에는 유용하지만 실제로 필요한 것보다 훨씬 짧게 설정하면 평균 속도에 부담이 됩니다.
• 리졸버와 권한 서버 사이의 네트워크 경로 문제: DNS 소프트웨어와는 전혀 무관한 패킷 손실, 라우팅 문제, 또는 가까운 애니캐스트가 없는 네임서버까지의 지리적 거리 등이 있습니다.

DNS를 다른 요소와 분리해서 보기

DNS가 실제로 병목인지 알아내는 가장 확실한 방법은 전체 페이지 로드와 별개로 조회 시간만 따로 측정하는 것입니다. 연결 수립, TLS 협상, 응답 다운로드와 독립적으로 시간을 잰 전용 조회를 보면 전체 지연 중 DNS가 차지하는 비중이 얼마인지, 혹은 아예 없는지 정확히 알 수 있습니다. 조회가 일관되게 한 자릿수 밀리초로 돌아오는데도 사이트가 느리게 로드된다면, 병목은 DNS보다 훨씬 하류에 있으므로 DNS를 더 튜닝해도 소용이 없습니다.

추측하기 전에 이를 확인해 볼 만합니다. “사이트가 느리다”는 불만 중 상당수는 서버나 사이트 코드와 전혀 관련이 없고, 전반적인 속도 저하처럼 보이는 다른 상당수는 사실 DNS에서 비롯된 것이어서 TTL이나 리졸버를 바꾸면 해결됩니다.

애니캐스트 리졸버가 대체로 빠른 이유

1.1.1.1이나 8.8.8.8 같은 공용 리졸버가 ISP의 기본 리졸버보다 대체로 빠른 것은 더 영리한 소프트웨어 때문이 아니라 애니캐스트 때문입니다. 같은 IP 주소가 전 세계 수십 곳의 물리적 위치에서 광고되고, 네트워크 라우팅이 질의를 토폴로지상 가장 가까운 곳으로 자동으로 보냅니다. 반면 ISP의 자체 리졸버는 데이터 센터 하나(또는 소수)인 경우가 많아, 그 위치와의 거리에 따라 왕복 시간이 실제로 더 길어질 수 있습니다. 리졸버를 바꾸는 것이 미신이 아니라 정당한 첫 번째 문제 해결 단계인 이유도 여기에 있습니다. 위약 효과가 아니라 물리적인 거리와 라우팅의 실제 차이를 해소하는 일이기 때문입니다.

나만이 아니라 모두에게 느릴 때

도메인이 하나의 네트워크와 리졸버가 아니라 여러 다른 네트워크와 리졸버에서 느리게 확인된다면, 문제는 “내 쪽에서 리졸버까지의 경로”에서 “도메인 자체의 권한 인프라”로 옮겨 갔을 가능성이 높습니다. 실제 방문자 상당수와 네트워크 거리가 먼 단일 비애니캐스트 권한 네임서버, 과부하 상태의 권한 서버, 또는 전송이 느린 대용량 DNS 존이 모두 이런 증상으로 나타날 수 있습니다. 이런 경우에는 단일 조회보다 여러 리졸버를 대상으로 한 일괄 비교가 더 진단에 도움이 됩니다. 모든 관측 지점에서 일관되게 느리다면 중간의 어느 한 네트워크가 아니라 상위, 즉 도메인 자체의 DNS 제공업체를 가리킵니다.