DNS 변경에 소요되는 시간

도메인의 A 레코드 (IP에서 다른 IP로 변경)에 대한 DNS 변경을하려는 경우 사람들이 새로운 정보로 옮겨 질 때까지 얼마나 오래 걸립니까? 단순히 <= TTL입니까? 시간이 오래 걸린다는 것을 알고 있지만 2009 년에 얼마나 오래 기다려야합니까?

이론적으로 모든 사람은 즉시 관련 TTL 값 사이에 업데이트 된 A 레코드를 볼 수 있습니다. 대부분의 등록 기관은 TTL을 24 시간 IIRC로 설정하므로 24 시간 동안 일부 사람들은 이전 주소를 볼 수 있고 일부는 새로운 주소를 볼 수 있으며 변경 후 24 시간이 지나면 모두 새로운 주소를 가져야합니다. 4 시간.

TTL 값을 변경할 수있는 액세스 권한이있는 경우 (예 : 내가하는 것처럼 자체 DNS 서버를 실행하는 경우) 변경하기 전에 TTL을 하루 정도 작은 것으로 줄이면 전파 기간이 훨씬 단축됩니다.

필자는 위의 "이론적으로"라고 말하면서 버그, 결함 및 잘못 구성된 캐시가 항상 있기 때문에 일부 사용자는 더 이상 변경 사항을 볼 수 없습니다. 주어진 값 미만의 TTL을 무시하는 DNS 캐시가있는 ISP가 여전히 있기 때문에 매우 작은 TTL을 사용하는 경우 특히 그렇습니다.

주의해야 할 또 다른 사항은 레지스트라의 DNS 제어판과 해당 DNS 서버 간의 지연입니다. 예를 들어 123-reg.co.uk에서 관리하는 도메인을 변경하면 DNS 서버에 표시되는 데 최대 1 시간이 걸릴 수 있음을 알았습니다. 이는 TTL 값을 초과하는 추가 시간입니다. .

클라이언트가 TTL 값에 따라 DNS 정보를 캐싱하는 시간에 따라 다릅니다. 그러나 클라이언트가 정보를 캐시하는 시간을 결정하므로 모든 클라이언트가 수동 해결을 수행하여 TTL을 완전히 무시한 후에는 확신 할 수 없습니다.

며칠 전에 IP 주소 변경이 발생한다는 것을 알면 일반적으로 TTL 값을 일반적으로 사용하는 것보다 적은 값으로 낮 춥니 다. 그렇게하면 변경하면 더 빨리 전파됩니다. 그런 다음 TTL을 다시 시작합니다.

일반적으로 TTL <=이지만 일부 클라이언트 및 DNS 프록시는 TTL보다 오래 이전 설정을 캐시합니다.

마이크와 동의했습니다. 우리는 일반적으로 24 시간에서 48 시간 동안 전 세계의 모든 ISP에게 전파하도록 고객에게 말합니다. 대부분의 주요 ISP는 TTL을 존중하며 신속하게 업데이트합니다. 원격 위치가 많을수록 시간이 더 걸립니다. 행운을 빕니다!

실용적인 목적으로 모든 DNS 서버는 A 레코드의 TTL 값과 즉각적으로 A 레코드가 변경된 것을 볼 수 있습니다. 위키 백과 문서는 이 주제에 대한 훌륭한 작성자가 있습니다.

라우터, 방화벽, 운영 체제 및 응용 프로그램 내의 로컬 DNS 캐시로 인해 개별 응용 프로그램이 TTL 내에서 변경 사항을 보지 못할 수 있습니다. Wikipedia 기사에서 언급 한 것처럼 : "이 캐시는 일반적으로 1 분 정도 매우 짧은 캐싱 시간을 사용합니다. Internet Explorer는 주목할만한 예외를 제공합니다. 최근 버전은 30 분 동안 DNS 레코드를 캐시합니다"

재부팅 (또는 라우터의 전원주기)은 일반적으로 모든 로컬 DNS 캐시를 플러시하지만 A 레코드를 변경 한 후 모든 사용자가 모든 장치를 재부팅 할 것으로 예상 할 수는 없습니다.

A 레코드를 직접 변경할 수없는 경우 응용 프로그램을 변경하면 (예 : 제어판 소프트웨어) 자체 지연이 발생할 수 있습니다.

기본 TTL은 4 시간입니다. A 레코드를 변경하려는 경우 A 레코드의 TTL을 5 분으로 줄입니다 (변경이 시작되기 전에 4 시간 이상 완료해야 함). 변경 후 TTL을 4 시간으로 되돌 렸습니다. 대부분의 응용 프로그램은 변경 사항을 즉시 확인하지만 일부 사용자는 문제가 발생하여 다시 부팅해야합니다.

Wikipedia 기사는 또한 "전파"에 대해 잘 설명하고 있습니다. "DNS를 변경할 때 많은 사람들이 신비한 48 시간 또는 72 시간의 전파 시간을 잘못 언급하고 있습니다. ..." 레지스트라가 아닌 루트 서버는 도메인의 NS 레코드에서 TTL을 제어합니다. nslookup 명령으로 이러한 TTL 값을 직접 확인할 수 있습니다. 현재 "F"루트 서버의 NS 레코드에 대한 TTL은 2 일로 설정되어 있습니다.

위에서 언급 한 모든 문제를 보완하기 위해 항상 사용자에게 전체 전파에 48 시간이 걸릴 것이라고 말합니다. 기억해야 할 일반적인 규칙은 TTL이 <=라는 것입니다. 실제로 TTL이 필요한 경우를 제외하고는 ...

TTL ( 사용자가 제어 하는 것 , Brian Clapper의 훌륭한 조언 참조) 및 일부 응용 프로그램 내에서 더 긴 캐싱 시간 외에도 신뢰할 수있는 이름 서버간에 동기화 시간도 있습니다. 모든 네임 서버가 NOTIFY를 수신하면 0에 가까울 수 있으며 NOTIFY가 누락 된 경우 (SOA 레코드 설정에 따라) 몇 시간이 될 수 있습니다 (때로는 발생하는 일).

따라서 Brian Clapper의 조언을 강조하려면 미리 계획하십시오.

Windows와 대화 중이고 내부 대화 중이라면 원래 TTL에 따라 다릅니다. 우리가 변경을 미리 알았을 때 A 레코드의 TTL을 5 분으로 낮게 설정했습니다. 그런 다음 변경이 이루어지면 TTL을 다시 정상적인 양으로 늘 렸습니다.

인터넷에서 이야기하는 경우 모든 베팅이 해제됩니다. 이미 언급했듯이 TTL을 완전히 무시한 일부 캐싱 도메인 컨트롤러가 있습니다. 그러한 경우 우리는 일반적으로 48 시간의 규칙을 적용했습니다. 그러나 도메인이 다른 공급 업체에 의해 이전에 호스트되었고 도메인에서 SOA를 제거하지 않은 경우 DNS 서버를 사용하는 클라이언트는 여전히 잘못 지적 될 것입니다. 우리는 BellSouth (현재 AT & T)에서 그 문제를 보았습니다.

나는 대부분의 사람들에게 평균 3-4 시간을 보았습니다. 그러나 여전히 완전한 전환을 위해 경험의 원칙으로 7 일을 사용합니다. 이것은 일반적으로 DNS TTL을 잘 사용하지 않는 모든 사람들을 대상으로합니다.

내 경험에 따르면 DNS 변경은 8 시간 이상 걸릴 수 있지만 이는 클라이언트가 DNS 설정을 캐시하는 시간에 달려 있습니다.

대부분의 클라이언트는 설정 한 TTL로 작업합니다. 그러나 TTL을 무시하도록 구성된 일부 DNS 서버가 있습니다. 최근에 우리 웹 사이트의 IP 주소를 변경했습니다. 요청에 응답하기 위해 몇 주 동안 서버를 이전 IP 주소로 유지해야했습니다. 우리는 남은 고객을 잘 파악하고 기존 IP에서 벗어나기 위해 DNS 캐시 및 / 또는 재부팅을 요청해야했습니다.

대체 된 레코드의 TTL보다 클 수 있습니다. 많은 클라이언트가 TTL이 너무 낮을 때이를 무시하거나 다른 값 (예 : 1 시간)으로 바인드합니다. 다른 캐시가 있습니다. Firefox (예를 들어) 는 1 분 동안 DNS를 캐시 하지만 (TTL 무시) 일부 패치 / 구성은이를 1 시간으로 늘립니다.

슬픈 (그러나 진실) 답변은 누가 당신의 (DNS) 답변을 요구하는지에 달려 있습니다.