요약

이 DNS 전파 확인 도구는 DNS 변경이 일부 리졸버에 보이지 않은 채 머무를 수 있는 시간을 추정합니다. 전파는 캐시 만료입니다. 리졸버는 TTL이 끝날 때까지 기존 응답을 유지하므로 최악의 경우는 기존 TTL과 같습니다. 새 레코드는 SOA 네거티브 TTL 동안 '없음'으로 캐시될 수 있고, 네임서버 전환은 레지스트리의 NS TTL을 따릅니다. 변경 유형, TTL, 수정 후 경과 시간을 입력하면 남은 대기 시간을 볼 수 있습니다. 브라우저에서 실행되며 실시간 DNS를 조회하지 않습니다.

DNS 전파 확인: 변경 사항이 반영되기까지 남은 시간

TTL과 변경을 저장한 후 경과한 시간을 입력하세요. 이 DNS 전파 확인 도구는 레코드 변경, 새 DKIM 키, 네임서버 전환에 대해 남은 최악의 대기 시간을 보여줍니다.

대기 시간 확인하기

DNS 전파 확인기

변경 유형을 고르고, 해당하는 TTL과 저장 후 경과한 시간을 입력하세요. 결과는 입력하는 대로 갱신되며, 어떤 데이터도 브라우저를 떠나지 않습니다.

레코드를 수정하기 전의 TTL이며, 새 TTL이 아닙니다.

작동 방식

이 계산기가 실제로 측정하는 것

전파는 캐시 만료입니다

DNS는 변경 사항을 어디로도 밀어 보내지 않습니다. 각 리졸버는 가져온 응답을 TTL이 끝날 때까지 보관하고, 그 뒤에 다시 묻습니다. 가장 느린 리졸버는 수정 직전에 기존 응답을 가져간 리졸버이므로, 최악의 경우는 기존 TTL과 같습니다.

새 레코드는 자체 타이머를 가집니다

존재하지 않던 레코드도 '없음' 응답으로 캐시될 수 있습니다. 그 네거티브 응답은 SOA TTL과 SOA 최소값 필드 중 작은 값만큼 유지됩니다. 아무도 해당 이름을 미리 조회하지 않았다면 새 레코드는 즉시 보입니다.

네임서버 변경은 레지스트리를 따릅니다

네임서버를 바꾸면 상위 존의 NS 레코드가 바뀌며, 이 TTL은 사용자가 설정할 수 없습니다. 계산기는 이 값을 입력으로 받으며, .com 같은 대형 TLD의 일반적인 값인 2일을 기본으로 씁니다.

이메일 DNS 변경 전에

대기 시간을 줄이는 네 단계

SPF, DKIM, DMARC, MX 레코드를 발신 도메인에서 수정할 때 우리가 쓰는 순서입니다.

  1. 1

    현재 TTL 확인

    레코드에 dig를 실행하고 ANSWER 섹션의 숫자를 읽으세요. 이 값이 변경이 넘어서야 하는 TTL입니다.

  2. 2

    미리 TTL 낮추기

    TTL을 300초로 설정한 뒤, 레코드를 수정하기 전에 기존 TTL 이상 기다리세요. 리졸버는 오래 유지되던 복사본을 먼저 만료시켜야 합니다.

  3. 3

    변경하고 시각 기록

    수정을 저장하고 시각을 적어 두세요. 그리고 위 계산기에 경과 시간을 입력하세요.

  4. 4

    원본에서 확인한 뒤 리졸버에서 검증

    먼저 권한 있는 네임서버를 조회한 다음 공개 리졸버를 조회하세요. 두 곳이 모두 새 값을 보여주고 대기 기간이 지나면 TTL을 다시 올리세요.

자주 묻는 질문

이 DNS 전파 확인 도구는 무료인가요?
네. 가입도 필요 없고 요청 횟수 제한도 없습니다. 계산은 입력한 세 가지 숫자에 대한 산술이므로 브라우저에서 실행되며, 아무것도 저희 서버로 전송되지 않습니다.
실시간 DNS 서버를 조회하나요?
아니요. 전 세계 리졸버에서 레코드를 조회하지 않습니다. 입력한 TTL에서 캐시된 응답이 살아남을 수 있는 가장 긴 시간을 계산합니다. 특정 리졸버가 지금 무엇을 반환하는지 보려면, 그 리졸버를 대상으로 dig를 실행하고 여기 표시된 기간과 비교하세요.
새 TTL이 아니라 기존 TTL로 추정하는 이유는 무엇인가요?
리졸버는 수정 전에 가져온 응답을 그때 함께 받은 TTL과 함께 캐시합니다. 같은 수정에서 TTL을 낮춰도 이미 기존 응답을 가진 리졸버에는 아무 영향이 없습니다. 새 TTL은 변경 후에 가져온 응답에만 적용됩니다.
네거티브 캐싱 TTL은 무엇이며 언제 적용되나요?
리졸버가 레코드가 없는 이름을 요청하면 '존재하지 않음' 응답을 캐시할 수 있습니다 (RFC 2308). 이 캐시는 SOA 레코드 자체의 TTL과 그 최소값 필드 중 작은 값만큼 유지됩니다. 레코드를 만들기 전에 해당 이름을 조회했던 리졸버에만 영향을 줍니다. 예를 들어 누군가 너무 일찍 테스트한 DKIM 셀렉터가 여기에 해당합니다.
네임서버 변경은 왜 이렇게 오래 걸리나요?
네임서버를 가리키는 NS 레코드는 레지스트리에 있으며, 그 TTL은 사용자가 제어할 수 없습니다. .com 같은 대형 TLD에서는 보통 2일입니다. 그 TTL이 만료되기 전까지 일부 리졸버는 계속 이전 네임서버에 질의합니다.
기간이 지났는데도 예전 값이 보입니다. 어떻게 해야 하나요?
캐시 탓만 하지 마세요. 권한 있는 네임서버를 직접 조회해 새 값을 제공하는지 확인하세요. 제공하지 않는다면 잘못된 존이나 잘못된 호스트 이름에 수정했거나 저장되지 않은 것입니다. 제공한다면 한 번도 사용하지 않은 리졸버에서 테스트하고, 본인 기기나 네트워크의 로컬 캐시도 확인하세요.
SPF, DKIM, DMARC 레코드에도 적용되나요?
네. 이들은 TXT 레코드이며 다른 레코드와 똑같이 캐시됩니다. 기존 SPF 레코드를 캐시한 수신 서버는 TTL이 끝날 때까지 그것을 계속 평가하므로, 수정 직후에 보낸 메일은 이전 정책으로 판정될 수 있습니다.

발신 인프라 전체를 관리하세요

이 도구는 대기 시간을 추정합니다. Notification Harbor는 직접 통제하는 발송을 다룹니다. 도메인 워밍업, 발송 단위 트레이스 가시성, 그리고 첫 프로덕션 발송 전에 올바르게 설정된 SPF, DKIM, DMARC를 제공합니다.

Notification Harbor 작동 방식 보기
notificationharbor
무료로 시작하기