DynamicDNS는 어떻게 즉시 작용합니까?

DNS의 핵심 기능에 대한 이해는 도메인 이름 blah-whatever.com(예 :) 과 IP 주소 (예 : 100.2.3.4 ) 사이의 이름 지정 / 매핑 서비스를 제공하는 것 입니다.

또한 인터넷 DNS 서버의 작동 방식에 대한 이해는 도메인 / IP 매핑 레코드가 변경 될 때 (예 : blah-whatever.com현재 105.2.3.4 등을 가리 키도록 변경 될 때 )이 변경 사항이 전 세계 모든 DNS 서버에 전파되어야한다는 것입니다. 변경이 "완료"되었다고 말할 수 있습니다. 이 전파 기간은 때때로 최대 24 시간 지속될 수 있습니다.

우선, 지금까지 말한 내용이 잘못 안내되거나 틀린 경우 먼저 수정 해주세요.

다소 정확하다고 가정하면 CloudFlare 또는 DynamicDNS와 같은 회사에서 DNS 레코드를 변경하고 붐 과 같은 변경 사항이 즉시 적용 되는 "인스턴트 롤오버"유형 서비스를 제공 할 수있는 방법을 이해하지 못합니다 .

이 인스턴트 롤오버 기능에서 중요한 역할을하는 "TTL"(살아가는 시간,?!?)이라는 것이 있다는 것을 알고 있습니다. 그러나 이미 시작하는 기능에 대해 애매 모호하므로 무엇을 이해하기 어렵습니다. 이 TTL은 어떤 용도로 사용됩니까?

따라서 동적 DNS와 경쟁 업체는 DNS 매핑을 즉시 변경하고 (다른 사람과 마찬가지로 DNS 변경 사항을 전파하는 데 24 시간이 소요되지 않음) TTL이이 프로세스에 어떻게 적용됩니까? 미리 감사드립니다.

DNS 변경이 전파되는 방법에 대한 몇 가지 오해가 있었기 때문에 이전 답변에 잘못된 정보가 포함되어 있습니다. 여기에 두 번째 시도가 있습니다. 자세한 설명은 Alex answer 를 읽으십시오 .

내 이해에는 DNS 변경이 얼마나 빨리 전파되는지에 관련된 두 가지 요소가 있습니다.

1. 영역에 권한이있는 DNS 서버간에 영역을 전송합니다.
2. 해당 영역의 단일 레코드에 설정된 TTL입니다.

영역 전송

영역을 관리하려면 두 개의 고유 한 이름 서버가 필요하므로 이러한 서버에서 해당 영역의 최신 버전을 빠르게 사용할 수 있기를 원합니다.

고정 된 간격으로 최신 버전의 영역을 가져 오거나 권한이 부여 된 이름 서버에서 NOTIFY 를 기다리면됩니다 .

이 메커니즘이 이름 서버를 실행하는 사람을 완전히 제어하고 있으므로이 영역의 지연을 완전히 제어 할 수 있습니다.

TTL

TTL이 영역에있는 모든 단일 리소스 레코드에 대해 지정된 시간 제한입니다. 이 값은 권한이없는 DNS 공급자가 레코드를 캐시해야하는 시간을 정의합니다.

이 값은 기존 레코드가 변경된 경우에만 적용됩니다 . 새 레코드는 아직 캐시 할 수 없습니다.

TTL이 영역을 제어하는 ​​사람을 완전히 제어 할 수 있기 때문에 지연을 완전히 제어 할 수도 있습니다.

약간의 오해가 있으므로 전체 프로세스를 설명하려고 노력할 것입니다. (공개 동적 DNS 서비스 운영에 관여했기 때문에 세부 사항에 만족합니다).

도메인이 example.com 이고 동적 DNS 회사와 호스팅 된 example.com 도메인을 lightfastdns.net (가상 이름) 이라고하겠습니다 . 도메인에 DNS 레코드 -somehost.example.com 이 있으며 현재 1.1.1.1을 가리 킵니다 .

1. DNS 레코드를 변경하면이 변경 사항이 먼저 lightfastdns.net에 의해 운영되는 일부 중간 서버 (예 : updates.lightfastdns.net)에 제출됩니다 . 이것은 거의 즉각적으로 발생합니다 (초 단위). 웹 인터페이스 또는 동적 업데이트 클라이언트 또는 일부 API를 통해 업데이트를 제출할 수 있습니다. 아무튼이 업데이트는 DNS 업데이트를 처리하는 일부 서버에 도착합니다.

2. 이 업데이트 서버는 업데이트 된 레코드 ( 1.2.3.4 )를 도메인의 " 마스터 "DNS 서버로 푸시합니다 . 이 DNS 서버는 lightfastdns.net에 의해 운영됩니다 . 발생 속도 : DNS 공급자가 소프트웨어를 설계 한 방법에 따라 다릅니다. (즉시 가능하며 24 시간마다 가능합니다. 예를 들어 gandi.net은 시간당 한 번 DNS 업데이트를 푸시합니다.) 물론 lightfastdns.net 은 즉시 수행합니다.

3. 이 마스터 DNS 서버는 example.com 도메인의 슬레이브 DNS 서버로 업데이트를 푸시 합니다. 이 서버는 같은 lightfastdns.net 회사 에서 운영합니다 . 최신 소프트웨어 마스터를 사용 하면 NOTIFY 메시지를 슬레이브에 즉시 보내고 마스터 에서 업데이트 된 레코드를 즉시받습니다. 구형 소프트웨어에서는 SOA 레코드에 REFRESH 및 RETRY 값이 있었지만 오늘날에는 거의 관련이 없습니다. 물론 lightfastdns.net 은 NOTIFY를 구현하고 업데이트는 즉시 전파됩니다.

우리가 지금 가지고있는 것은 도메인에 대한 모든 "권한있는"서버가 업데이트 된 레코드 ( 1.2.3.4 )를 받았다는 것 입니다. 들어 lightfastdns.net 이 2 초 걸렸다.

1. 이제 러시아에있는 Ivan의 집으로 옮길 것입니다. Ivan은 브라우저에서 " somehost.example.com " 을 열려고 합니다. 그가 이전에 열어 본 적이 없다면, 브라우저는 주소를 알지 못하므로 브라우저는 운영 체제를 묻습니다 . 그러나 최근에 사이트를 방문한 경우 주소는 여전히 브라우저 내부에 저장 될 수 있으며 이전 (사용되지 않는) 주소를 사용합니다! 얼마나 오래? -브라우저에 따라 Chrome은 예를 들어 DNS 레코드를 최대 60 초 동안 만 저장합니다. 지연 시간은 최대 60 초 입니다. 사실 DNS 변경 이이 브라우저로 전파 되지 않았다고 말하고 싶습니다 .

2. 어쨌든 60 초 후 또는 즉시 브라우저는 운영 체제에 주소를 요청합니다. 운영 체제는 이미 (오래되고 쓸모없는) 대답을 알고 답을 반환 할 수 있습니다.이 경우 새 레코드가 아직 Ivan의 OS로 전파 되지 않았다고 말하고 싶습니다 . OS가 이전 값을 저장하는 기간-최신 운영 체제는 TTL 매개 변수로 제어됩니다 . DNS의 TTL 은 레코드가 캐시에 저장 될 수있는 기간을 정의합니다. 우리의 lightfastdns.net 은 30 초의 매우 낮은 TTL을 사용할 수있었습니다. 그래서 우리는 지금까지 총 90 초 , 최대 30 초의 새로운 지연을 얻었습니다 .

3. OS가 답을 알지 못하거나 알고있는 답이 이제 TTL에 의해 구식 인 경우, OS는 DNS 확인자 (Ivan의 ISP가 DNS 확인자 dns.moscow-telecom.ru로 지정 )를 요청합니다. 여기에 이전 레코드는 최대 TTL 초까지 캐시되거나 dns.moscow-telecom.ru 가 주소를 알지 못할 수 있습니다. dns.moscow-telecom.ru 는 TTL 값을 초과하여 DNS를 캐시하기 때문에 30 초가 더 걸립니다. 지연 시간 은 120 초 입니다. 이것이 새로운 DNS 레코드가 아직 Moscow-Telecom의 DNS 서버로 전파되지 않았다는 것 입니다.

4. ISP의 DNS 서버는 답을 알고하지 않습니다, 또는 알고 대답은 그것의 TTL이 만료되어 이미 사용되지 않는 경우 경우 - dns.moscow-telecom.ru는 하나 요청합니다 AUTHORITATIVE 에 대한 DNS 서버 example.net를 (? 당신이 그들을 기억하지). 약 118 초 전에 변경 사항이 있었고 새로운 답변을 반환 할 것입니다.이 답변은 체인을 통해 DNS 확인자, OS 및 Ivan의 브라우저로 즉시 전송됩니다.

따라서 다양한 캐시의 상태에 따라 레코드를 전파하는 데 2 ​​초에서 120 초가 걸렸습니다. 더 긴 TTL-더 긴 지연이 발생할 수 있습니다.

완료하기 위해 일부 ISP는 표준 및 캐시 레코드를 오랫동안 위반합니다. 일부 구형 OS는 오래된 레코드와 오래된 브라우저를 오랫동안 유지했습니다. 그러나 대부분의 사용자에게는 예상대로 작동합니다.

변경 사항이 전세계 모든 DNS 서버 로 전파 될 필요 는 없습니다 .

무언가를 변경하고 누군가가 DNS 서버에서 변경된 레코드를 쿼리하면 결과는 즉각적입니다.

문제는 이전에이 이름을 쿼리하여 캐시 한 경우입니다. 그런 다음 캐시가 만료 될 때까지 이전 IP를 얻습니다. DNS에서 이전 쿼리의 유효 기간을 설정할 수 있으며이 기간은 종종 며칠로 설정됩니다. DynDNS의 경우 일반적으로 낮게 설정되지만 모든 DNS 확인자가이를 준수하는 것은 아닙니다.