요즘 이름 서버의 몇 퍼센트가 TTL을 인정합니까? 우리를 무시하고

몇 년 전 몇 주 동안 여러 데이터를 한 데이터 센터에서 다른 데이터 센터로 옮길 때 몇 가지 DNS 변경을 수행해야했습니다. 필자가이 작업을 수행 한 시점에서 전 세계 네임 서버의 약 95 %가 TTL 값을 존중하는 것처럼 보였으며, 약 5 %는 우리를 무시하고 자체적으로 구성했습니다. 다시 말해, 트래픽의 95 %가 우리가 정의한 15 분 TTL 내에서 이동했습니다. 또 다른 3 %가 첫 시간에, 첫날에 1 %를 만들었고, 몇 명의 꼬챙이는 최대 3 일이 걸렸습니다.

(예, 알겠습니다. 트래픽 비율과 네임 서버 비율이 혼동됩니다. 핸드 파잉을 삽입하십시오.)

그러나 이것은 2001 년경에 이루어졌으며 공룡을 사용하여 튜브를 통해 패킷을 전송했습니다. 내 생각 엔 오늘날의 네임 서버가 더 잘 작동하며, 스트로 글러에 대한 문제는 줄어들 것입니다. 요즘 정의 된 TTL 내에서 몇 퍼센트의 트래픽이 전환 될지 느끼는 사람이 있습니까? TTL을 무시하는 네임 서버가 여전히 있습니까?

답변

우리는 최근에 이사했고 DNS에 모든 종류의 문제가있었습니다.

우리가 대부분의 고객을 돌파하자 새로운 IP를 바로 시작했습니다. 그러나 일부는 여전히 몇 주 동안 기존 IP를 사용하고있었습니다. 한 달 정도 서버를 두었습니다. 결국 우리는 이전 머신의 IIS 로그를 살펴보고 회사 나 ISP DNS 서버에서 DNS를 플러시하도록 고객에게 요청했습니다. 마지막으로 이동했습니다.

오래된 IP를 유지 한 사람은 소수였습니다. 20K 고객 중 50 일은 첫날 이후에 문제가 발생했을 수 있습니다.

답변

(매우) 긴 TTL 주 값은 2011 년 5 월에 최대 2 주 동안 대부분의 DNS 확인 네임 서버에서 인정합니다.

just-dnslookup.com을 사용한 테스트에서 A 레코드 TTL이 99.999.999 = 165 주 (정확도 : 165 주 2 일 9 시간 46 분 39 초)로 설정된 50 개의 전역 분산 활성 측정 포인트 및 기본 TTL 2 주 중 (= SOA + NS TTL)

첫 조회 는 다음을 반환합니다.

  • 1 주일의 TTL, 50 개 측정 포인트 중 3 개
  • 50 개 측정 지점 중 47 개에 대해 165주의 TTL

연속 조회가 리턴됩니다 (원래 TTL 값으로 변환 됨).

  • 1 주일의 TTL, 50 개 측정 포인트 중 3 개
  • 50 개 측정 포인트 중 46 개에 대해 2주의 TTL
  • 50 개 측정 포인트 중 1 개에 대해 165주의 TTL

기본 TTL이 4 주 (= SOA + NS TTL)로 설정된 두 번째 테스트 (다른 ​​도메인 사용)는 다음과 같습니다.

첫 조회 는 다음을 반환합니다.

  • 1 주일의 TTL, 50 개 측정 포인트 중 3 개
  • 50 점 중 1 점에 대해 2주의 TTL
  • 50 개 측정 포인트 중 46 개에 대해 165주의 TTL

연속 조회가 리턴됩니다 (전체 TTL 길이로 변환 됨).

  • 1 주일의 TTL, 50 개 측정 포인트 중 3 개
  • 50 개 측정 포인트 중 47 개에 대해 2주의 TTL
  • 50 개 측정 포인트 중 0 개에 대해 165주의 TTL

가장 잘 알려진 / 최고로 연결된 공개 리졸버 서비스에서 :

  • Google 공개 DNS [8.8.8.8 및 8.8.4.4]는 1 일로 줄었습니다.
  • UltraDNS [rdns (1 | 2) .ultradns.net]은 165 주 전체를 존중합니다.
  • Sprintlink [ns (1 | 2 | 3) .sprintlink.net]는 165 주 동안 상을 받았습니다.

답변

최근에 개인 사이트 및 프로젝트 사이트를 호스팅하는 몇 개의 도메인에 대한 DNS를 GoDaddy에서 사내 DNS (예 : 내 집 ) 로 옮겼습니다 . 전반적으로, 내가 원격 액세스 권한을 가진 모든 사이트는 TTL을 존중하고 전환을 잘했습니다. 유선 전화와 모바일을 통해 확인을 요청할 수있는 모든 친구가 동일한 내용을보고했습니다. 아이러니하게도 유일한 문제는 내가 일하는 $ Uniiversity의 주요 캐싱 DNS 서버였습니다. 캐시 된 쿼리의 TTL을 완전히 무시하고 캐시 된 결과에 할당 한 TTL 값을 무시하는 것 같습니다.

전반적으로 TTL은 존중받는 것 같습니다. .com 및 .net 도메인에 대해 권한이있는 서버의 56 %가 BIND를 실행하고 있으며 이는 분명히 표준과 잘 어울립니다. Cablevision / Optimum (적어도 NJ)은 TTL을 준수하는 Nominum CNS를 사용하는 것 같습니다.

답변

이것은 특별히 귀하의 질문에 대한 답변이 아닙니다. 오히려 테스트에서 고려해야 할 추가 사항 :

연결 DNS 리 커서 및 캐싱 데몬

레코드를 캐시하는 것은 에지 DNS 리커서만이 아닙니다. 때때로 사람들은 체인을 반복하며 시간이 더 걸립니다. 이 작업을 수행해야하는지 여부는 사람들이 해결하려는 내용에 따라 긴 토론이 될 수 있습니다. 데이터 센터에서 3 단계의 재귀를 보았습니다. TTL 감소가 항상 유지되는 것은 아니기 때문에 혼합 순환기는 혼합 결과를 가질 수 있습니다. 일부 운영 체제는 레코드를 캐시합니다. 일부 시스템은 또한 같은 것들을 사용 nscd, dnsmasq지역 recursor 문제의 영향을 최소화하기 위해 자신의 recursors에 부하를 줄이기 위해 다른 방법을. OS의 특성은 릴리스 버전, 캐싱 데몬, 캐싱 데몬 버전 등에 따라 다릅니다.

[편집] 으로의 투자 의견이는 recursor 또는 캐시 데몬의 정상적인 동작하지 않습니다. 나는 버그가있는 것을 부끄러워하지 않을 것이지만 많은 리눅스 배포판과 함께 번들로 제공되지만 그 중 하나는 유지되지 않은 것으로 간주됩니다.

응용 프로그램 DNS 캐시

일부 브라우저는 또한 레코드를 캐시합니다. Java 및 기타 앱도 DNS를 캐시합니다. 때로는 응용 프로그램 내에서 최대 ttl을 제한 할 수 있습니다.

최종 결과가 왜곡 될 수 있음

위 항목은 15 분 TTL을 60 분 이상으로 쉽게 바꿀 수 있습니다.

그렇기 때문에 응용 프로그램이나 웹 사이트가 내결함성 디자인에 여러 개의 활성 노드를 두어야한다고 제안하는 이유가 있습니다. 따라서 클라이언트는 사이트에 대한 진입 점이 실패 할 때 더 빠르게 결정할 수 있고 우아하고 예측 가능한 매너에서 자동으로 문제를 처리 할 수 ​​있습니다. 가능할 때. 애니 캐스트 는 일부 회사에서 장애 조치를 다소 투명하게하고 DNS 변경에 크게 의존하지 않는 방법 중 하나입니다. 여러 DNS 레코드를 사용하여 자바 스크립트에서 수행 할 수있는 영리한로드 밸런싱 방법도 있습니다.

답변

오래된 질문이지만 새로운 답변 (2017 년, 6 년 후) :

  1. 거의 모든 전세계 DNS 서버가 5 분 안에 업데이트되는 것처럼 보입니다.
  2. Google 및 OpenDNS를 사용하면 수동으로 DNS 레코드를 플러시하여 전파 업데이트 속도를 높일 수 있습니다

아래 실험 전에 TTL을 14400 (초 = 4 시간)에서 300 (초 = 5 분)으로 이전에 변경했지만 실험 2 시간 전에이 작업을 수행했으며 이전 TTL이 4 시간 이후로 변경 사항이 확실하지 않습니다. DNS 서버에 자체 최소 TTL이 없으면 알아낼 수 있습니다.

내 실험 :

실험 1 :

권한있는 서버에서 이름 -IP 변환 (A 레코드)을 변경 한 다음 확인했습니다.

5 분 (300 초) 후에 해당 사이트에서 확인한 글로벌 서버의 약 절반이 업데이트되었습니다.

7 분 후, 1을 제외한 모든 것이 업데이트되었습니다.

실험 2 :

Google 및 OpenDNS를 사용하면 특정 도메인에 대한 DNS 캐시를 수동으로 플러시 할 수 있습니다. 모래밭:

다른 A 레코드를 업데이트 한 후 즉시 Google의 DNS 캐시를 비 웠습니다. 그들은 “표지가있는 모든 정사각형을 클릭”하게하는 보안 문자를 가지고 있으므로 플러시를 완료하기까지 1-2 분이 걸렸습니다.

4 분 후 해당 사이트에서 확인한 1 개의 DNS 서버 만 이전 IP 주소를 가졌습니다. 다른 모든 것이 업데이트되었습니다.

따라서 Google의 DNS 캐시를 지우고 권한있는 서버를 다시 쿼리하도록 강요하면 전 세계 서버에서 캐시 업데이트를 트리거하여 글로벌 DNS 전파를 가속화 한 것으로 보입니다.

그러나 Google 플러시가 없어도 전파는 몇 시간 또는 며칠이 아닌 몇 분 안에 나타납니다.

답변