DNS 전파 확인

DNS 전파 확인은 같은 도메인의 레코드를 서로 다른 공개 리졸버에 동시에 질의해, 변경한 DNS 설정이 인터넷 전체에 얼마나 퍼졌는지 가늠하는 도구입니다. 네임서버를 바꾸거나 A·MX 레코드를 수정한 뒤, 일부 사용자에게는 새 값이 보이고 다른 사용자에게는 옛 값이 보이는 “전파 중” 구간을 눈으로 확인할 수 있습니다.

이 도구는 Cloudflare와 Google 두 공개 리졸버에 DNS over HTTPS로 질의한 뒤 결과를 나란히 비교합니다. 두 리졸버의 응답이 같으면 일관(전파됨), 다르면 아직 전파 중으로 표시합니다. 단순 단일 조회가 필요하면 DNS 레코드 조회 도구를, 위임된 네임서버는 네임서버(NS) 확인으로 다시 확인하세요.

전파(propagation)란 무엇인가

DNS는 전 세계 수많은 리졸버가 레코드를 각자의 TTL만큼 캐싱하는 분산 시스템입니다. 권한 네임서버에서 값을 바꿔도, 이미 옛 값을 캐싱한 리졸버는 캐시가 만료될 때까지 새 값을 가져오지 않습니다. 이 “캐시가 빠지고 새 값이 채워지는 과정”을 흔히 전파라고 부릅니다.

결과를 읽는 법

• 일관(전파됨): 두 리졸버가 동일한 레코드 집합을 반환 — 변경이 충분히 퍼진 상태.
• 불일치(전파 중): 리졸버마다 값이 달라 아직 옛 캐시가 남아 있는 상태.
• 값의 순서는 무시하고, 정규화(소문자·끝점 제거)한 집합으로 비교합니다.

전파를 빠르게 하려면

변경 예정인 레코드의 TTL을 미리 낮춰두면(예: 300초) 캐시 만료가 빨라져 전파가 짧아집니다. 변경이 끝나면 다시 TTL을 올려 조회 부하를 줄이세요. NS 레코드 자체를 바꾸는 위임 변경은 상위 레지스트리 TTL의 영향을 받아 더 오래 걸릴 수 있습니다.

전파 속도를 좌우하는 요인

“전파가 얼마나 걸리나”에 정답은 없습니다. 아래 요인들이 겹쳐서 실제 체감 시간이 정해집니다. 변경 전에 이 표로 예상 시나리오를 잡아두면 불필요한 조바심을 줄일 수 있습니다.

예시로 보는 전파

예를 들어 www.example.com의 A 레코드를 203.0.113.10에서 203.0.113.20으로 바꿨고, 이 레코드의 TTL이 3600초였다고 합시다. 변경 직후 처음 조회하는 사용자는 새 IP203.0.113.20을 바로 받지만, 변경 직전에 옛 값을 캐싱한 리졸버를 쓰는 사용자는 캐시가 만료될 때까지(최대 1시간) 여전히 203.0.113.10을 봅니다. 이 도구에서 Cloudflare는 새 IP, Google은 옛 IP를 반환한다면 “불일치(전파 중)”로 표시되고, 한 시간 안에 두 리졸버 모두 새 IP로 수렴하면 “일관(전파됨)”이 됩니다. 그래서 계획된 변경 전에는 미리 TTL을 300초 정도로 낮춰두는 것이 가장 효과적입니다.

• 증상: 일부 사용자만 옛 사이트/IP를 본다 → 원인: 리졸버에 옛 TTL 동안 캐시가 남음 → 조치: TTL만큼 기다리거나, 다음을 대비해 변경 전 TTL을 낮춘다.
• 증상: NS 변경 후 하루가 지나도 일부 미반영 → 원인: 상위 TLD의 긴 TTL → 조치: 최대 48시간까지 여유를 두고 양쪽 NS를 동시에 유지한다.