DNS 전파 확인 도구(무료・전 세계 DNS 서버 일괄 조회)
Google, Cloudflare 등 전 세계 여러 공개 DNS 리졸버에 도메인의 DNS 레코드를 무료로 동시에 조회하여, 네임서버 변경 사항이 전 세계에 이미 전파되었는지 한눈에 비교해서 보여줍니다.
DNS 변경이 세계에 두루 퍼졌는지 확인하기
이 도구는 도메인의 DNS 레코드를 구글과 Cloudflare를 비롯한 세계 각지의 공개 리졸버에 한꺼번에 물어, 돌아온 답을 나란히 놓고 견주게 해 줍니다. 네임서버를 옮긴 직후나 A 레코드를 고쳐 쓴 직후에 변경이 어디까지 갔는지를 한눈에 짚을 수 있습니다.
**「전파」라는 말은 사실 다소 오해를 부릅니다.** DNS는 변경을 각지로 밀어 보내는 장치가 아닙니다. **각 리졸버가 앞선 답을 캐시에 지닌 채, 그 기한(TTL)이 다할 때까지 옛 값을 계속 돌려줄 뿐입니다.** 그러니 기다림의 길이는 **변경하기 전에 걸려 있던 TTL이 정합니다.** 변경한 뒤에 TTL을 줄여도 이미 나눠 준 캐시에는 듣지 않습니다. **바로 그래서 옮길 계획이 있다면 며칠 앞서 TTL을 낮춰 두는** 것이 정석입니다. 여기서 답이 서로 어긋나는 것은 탈이 아니라, 캐시가 아직 다하지 않았다는 뜻입니다.
사용하는 방법
- 도메인과 레코드 종류를 지정합니다 A·MX·TXT 등 확인하고 싶은 종류를 고릅니다.
- 각 리졸버의 답을 견줍니다 **새 값과 옛 값이 섞여 있다면 아직 갈아타는 중입니다.**
- 어긋나는 지역을 짚습니다 어느 리졸버가 옛 값을 지니고 있는지 알 수 있습니다.
- TTL만큼 기다립니다 **변경 전에 걸려 있던 TTL이 다하기까지는 기다리는 것 말고 할 일이 없습니다.**
더 잘 활용하기 위한 팁
- 네임서버나 A 레코드를 변경한 직후에는 TTL（캐시 유효 기간）이 만료되기 전까지 일부 리졸버가 이전 값을 계속 반환할 수 있는데, 이는 오류가 아니라 정상적인 현상입니다.
- 리졸버마다 값이 다르게 나온다면 먼저 TTL을 확인하세요. TTL이 길수록（예: 24시간）모든 곳에 전파가 완료되기까지 자연히 더 오래 걸립니다.
- 이 도구는 A 레코드뿐 아니라 MX·TXT（SPF/DKIM 등）레코드의 변경 확인에도 사용할 수 있습니다. 이메일 관련 설정을 변경한 뒤에는 TXT도 꼭 확인하세요.
- "NXDOMAIN" 응답은 도메인 자체가 존재하지 않는다는 뜻입니다. 오타나 도메인 만료 여부를 확인해 보세요.
- 이 도구는 일본 국내 리졸버뿐 아니라 해외 리졸버에도 조회하므로, 해외 사용자를 대상으로 한 전파 상태를 파악하는 데도 유용합니다.
이럴 때 쓸 수 있습니다
네임서버를 옮긴 직후에
**이관이 세계적으로 반영되었는지를 확인할 수 있습니다.**
서버를 갈아탈 때
그 이름이 이제 새 주소를 가리키는지 확인할 수 있습니다.
나만 안 보이는 까닭을 찾을 때
**내 쪽 리졸버만 옛 값을 지니고 있다면 다른 곳의 답과 견주어 가려낼 수 있습니다.**
갈아타는 작업을 계획할 때
기다림의 길이에서 거꾸로 셈해 TTL을 낮출 때를 정할 수 있습니다.
DNS 전파 용어
- 리졸버
- 이용자를 대신해 DNS를 찾아 주는 서버입니다. 구글의 `8.8.8.8`과 Cloudflare의 `1.1.1.1`이 대표적입니다.
- TTL
- 답을 캐시해도 되는 초수입니다. **기다림을 정하는 것은 변경 뒤가 아니라 변경 전의 TTL입니다.**
- 부정 캐시
- 「그런 레코드는 없다」는 답도 캐시됩니다. **새로 만든 레코드가 처음에 보이지 않는 까닭이 이것일 때가 있습니다.**
- 권위 서버
- 그 도메인의 바른 답을 지닌 서버입니다. 리졸버는 여기에 물어 답을 얻습니다.
- 네임서버
- 도메인의 관리를 맡은 권위 서버입니다. 이관하면 이것이 바뀝니다.
- 전파
- 변경이 각지의 리졸버에 두루 닿는 일을 이르는 관용어입니다. **실제로는 배포가 아니라 캐시가 다하기를 기다리는 과정입니다.**
자주 묻는 질문
여담 ― DNS "전파"는 누군가 능동적으로 퍼뜨리는 것이 아니다
DNS는 1983년에 처음 설계될 때부터 "계층적 캐시"를 전제로 만들어졌습니다. 전 세계의 모든 리졸버가 매번 루트 서버까지 거슬러 올라가 질의를 해결해야 한다면 시스템이 버틸 수 없기 때문에, 각 리졸버는 한 번 받은 응답을 레코드의 TTL（Time To Live）기간 동안 자체 캐시에 보관하고, 같은 질문이 들어오면 캐시에서 즉시 응답합니다. 이 구조 덕분에 DNS는 빠르지만, 그 대가로 "변경 사항이 전 세계에 반영되기까지의 지연"이라는 부작용도 생겼습니다.
이 지연을 흔히 "DNS 전파（DNS Propagation）"라고 부르지만, 실제로 누군가가 정보를 전 세계에 능동적으로 퍼뜨리는 것은 아닙니다. 정확히 말하면, 각 리졸버가 가진 오래된 캐시가 자신의 TTL 일정에 따라 조용히 만료되고, 다음에 누군가 질의할 때 비로소 새 값을 다시 가져오는 수동적인 교체가 누적되는 과정입니다. TTL을 24시간으로 설정했다면, 이론상 어딘가의 리졸버는 변경 후 24시간 내내 이전 값을 계속 반환할 수 있습니다.
이 도구가 사용하는 DoH（DNS over HTTPS）는 원래 2018년 전후로 Mozilla와 Google이 "ISP나 네트워크 경로상의 제3자가 DNS 질의 내용을 들여다보지 못하게 하자"는 개인정보 보호 목적으로 보급을 추진한 기술입니다. HTTPS 통신 속에 DNS 질의를 숨겨 암호화하는 것이 주된 목적이었지만, 그 부산물로 이 도구처럼 서버를 통해 여러 공개 리졸버에 손쉽게 질의할 수 있는 표준화된 JSON API도 함께 널리 퍼졌습니다.