Frage Welcher Prozentsatz von Nameservern würdigt TTL in diesen Tagen?


Vor einigen Jahren musste ich mehrere DNS-Änderungen im Laufe von mehreren Wochen vornehmen, als ich Teile von Geräten von einem Rechenzentrum zum anderen bewegte. Zu der Zeit, als ich das tat, schienen etwa 95% der Nameserver in der Welt den TTL-Wert zu respektieren, und etwa 5% ignorierten unsere und machten ihre eigenen aus. Mit anderen Worten, 95% des Traffics bewegten sich innerhalb der von uns definierten 15-Minuten-TTL. Weitere 3% schafften es in der ersten Stunde, 1% am ersten Tag, und ein paar Nachzügler brauchten bis zu drei Tage.

(Ja, OK, ich verwechsle den Prozentsatz des Traffics mit dem Prozentsatz der Nameserver. Bitte geben Sie Handwaving ein.)

Das war ungefähr 2001, und wir benutzten Dinosaurier, um Pakete durch die Röhren zu übertragen. Ich schätze, dass die heutigen Nameserver sich besser benehmen, und es wird weniger Probleme mit Nachzüglern geben. Hat jemand ein Gespür dafür, wie viel Prozent des Verkehrs innerhalb der definierten TTL in diesen Tagen wechseln wird? Gibt es noch viele Nameserver, die TTL ignorieren?


26
2017-10-08 00:12


Ursprung


Ich habe keine Ahnung, aber mein Bauchgefühl ist, dass es heute noch schlimmer als in der Vergangenheit sein wird. - Zoredache
Ich hätte es geliebt, sie alle in 3 Tagen fertig zu haben! In dieser Zeit habe ich eine große Veränderung vorgenommen (vielleicht 2002), und nach zwei Wochen stellten wir schließlich fest, dass 1/3 der Root-Nameserver auf einige Entwicklungs-DNS-Server schauten, die einer der anderen Sysadmins veröffentlicht hatte zur Außenwelt. (Ich habe immer noch keine Ahnung, wie die Root-Server von ihnen wussten). - Joe H.
Folgendes ist zu beachten: Es sind nicht nur Edge-DNS-Recursoren, die Datensätze zwischenspeichern. Manchmal verketten Leute Rekursoren und das fügt Zeit hinzu. Außerdem speichern einige Betriebssysteme Datensätze im Cache. Einige Browser cachen auch Datensätze. Java und andere Apps cachen auch DNS. Dies kann eine 15-minütige TTL in 60+ Minuten verwandeln. - Aaron


Antworten:


Wir sind kürzlich umgezogen und hatten alle möglichen Probleme mit DNS.

Als wir den Swing überstanden hatten, begannen die meisten Kunden sofort mit den neuen IPs. Aber einige trafen noch Wochen lang die alten IPs. Wir haben einen Server für einen Monat oder so verlassen. Schließlich gingen wir durch die IIS-Protokolle auf dem alten Computer und riefen die Kunden an, ihnen zu sagen, sie sollten DNS auf ihren DNS-Servern von Unternehmen oder ISP löschen. Das hat den letzten von ihnen bewegt.

Es war eine kleine Anzahl von Leuten, die bei den alten IPs blieben. Von 20k Kunden hatten vielleicht 50 nach dem ersten Tag Probleme.


15
2017-10-08 18:48



Vielen Dank! Das ist ungefähr das, was ich erwartet habe. Ein Viertel Prozent ist nicht schlecht für einige Arten von Verkehr, obwohl es für andere sehr schlecht ist. - user10501
Eine neuere Schätzung: 13 Stunden nach einem DNS-Server-Wechsel kontaktierten uns insgesamt 17/500 (3,4%) der Kunden, weil sie immer noch die alte statt die neue Seite betreuten. WhatsMyDNS ist praktisch, um den Status der Verbreitung zu überprüfen (in unserem Fall 4/140 = 2,85% der Server in ihrer Probe verwenden immer noch die alte / falsche IP - ich wünschte, ich hätte dies früher genutzt, um besser mit Kunden zu kommunizieren und zu verfolgen die DNS-Verbreitung.) - Fabien Snauwaert
Wenn ich erneut eine DNS-Änderung durchführen würde, würde ich im Voraus einen Backup-Domainnamen einrichten, um die neue Site zu bedienen, während die alte noch weiter verbreitet wird. - Fabien Snauwaert


(Sehr) lange TTL-Werte von Wochen werden im Mai 2011 von den meisten DNS-auflösenden Nameservern bis zu 2 Wochen geehrt.

In einem Test mit just-dnslookup.com, mit 50 globalen verteilten aktiven Messpunkt, mit einem A-Record TTL auf 99.999.999 = 165 Wochen (präzise: 165 Wochen 2 Tage 9 Stunden 46 Minuten 39 Sekunden) und eine Standard-TTL festgelegt von 2 Wochen (= SOA + NS TTL).

Erstes Nachschlagen kehrt zurück:

  • eine TTL von 1 Woche, für 3 von 50 Messpunkten
  • eine TTL von 165 Wochen, für 47 von 50 Messpunkten

Konsekutives Nachschlagen Rückgabe (konvertiert in den ursprünglichen TTL-Wert):

  • eine TTL von 1 Woche, für 3 von 50 Messpunkten
  • eine TTL von 2 Wochen, für 46 von 50 Messpunkten
  • eine TTL von 165 Wochen für 1 von 50 Messpunkten

Ein zweiter Test (unter Verwendung einer anderen Domäne), bei dem die Standard-TTL auf 4 Wochen gesetzt ist (= SOA + NS TTL), sind unten aufgeführt.

Erstes Nachschlagen kehrt zurück:

  • eine TTL von 1 Woche, für 3 von 50 Messpunkten
  • eine TTL von 2 Wochen, für 1 von 50 Messpunkten
  • eine TTL von 165 Wochen für 46 von 50 Messpunkten

Konsekutives Nachschlagen Rückgabe (konvertiert in volle TTL-Länge):

  • eine TTL von 1 Woche, für 3 von 50 Messpunkten
  • eine TTL von 2 Wochen, für 47 von 50 Messpunkten
  • eine TTL von 165 Wochen für 0 von 50 Messpunkten

Von den bekanntesten / am besten verbundenen öffentlichen Resolver-Diensten:

  • Google public DNS [8.8.8.8 und 8.8.4.4] reduziert sich auf 1 Tag.
  • UltraDNS [rdns (1 | 2) .ultradns.net] honoriert volle 165 Wochen.
  • Sprintlink [ns (1 | 2 | 3) .sprintlink.net] honoriert volle 165 Wochen.

8
2018-05-08 15:27



Persönlich wäre ich viel mehr darüber besorgt, ob kurz TTL-Einstellungen werden berücksichtigt. Haben Sie diesbezüglich ähnliche Untersuchungen durchgeführt? Wenn TTL beispielsweise auf 3600 Sekunden festgelegt ist, werden die zwischengespeicherten Datensätze wirklich nach einer Stunde ablaufen? Dies ist für eine Übernahmesituation sehr relevant. Der Gedanke, dass ein 165-Wochen TTL geehrt werden könnte, ist ziemlich beängstigend, besonders wenn man über Situationen nachdenkt, in denen man mich nach den Fehlern eines anderen aufräumen muss. - Skyhawk
Ich denke, 8.8.8.8 ignoriert komplett TTL und verwendet nur 24h. Es werden zumindest einige niedrigere Ttls nicht beachtet. Jetzt muss ich etwas für 24h finden. - Steven Parkes


Ich habe kürzlich DNS für einige Domains verschoben, auf denen meine persönlichen Websites und Projektwebsites von GoDaddy zu hausinternem DNS gehostet werden (ja, wörtlich meine Haus). Insgesamt respektierte jede Site, auf die ich Fernzugriff hatte, die TTL und machte den Übergang gut. Das gleiche berichtete jeder Freund, den ich fragen konnte, sowohl über Festnetz als auch über Handy. Das einzige Problem, ironischerweise, waren die Haupt-Caching-DNS-Server bei $ University, wo ich arbeite, die TTL für zwischengespeicherte Abfragen völlig ignorierten (und sogar den TTL-Wert ignorierten, den sie dem zwischengespeicherten Ergebnis zuordneten).

Insgesamt scheint TTL respektiert zu werden. 56% der Server sind für .com- und .net-Domänen autorisierend laufen BIND, was offensichtlich gut zu den Standards passt. Cablevision / Optimum scheint (zumindest in NJ) Nominal CNS zu verwenden, das auch TTLs berücksichtigt.


3
2017-10-08 03:03





Dies ist keine spezifische Antwort auf Ihre Frage. Es sind jedoch zusätzliche Dinge zu berücksichtigen, die in Ihre Tests einfließen:

Verkettete DNS-Rekursoren und Cachedämonen

Es sind nicht nur Kanten-DNS-Recursoren, die Datensätze zwischenspeichern. Manchmal verketten Leute Rekursoren und das fügt Zeit hinzu. Ob dies getan werden sollte oder nicht, könnte eine lange Diskussion sein, basierend auf dem, was die Leute zu lösen versuchen. Ich habe 3 Rekursionsebenen in einem Datencenter gesehen. Mischrekursoren können gemischte Ergebnisse haben, da die TTL-Dekremente nicht immer beibehalten werden. Einige Betriebssysteme cachen Datensätze. Einige Systeme verwenden auch Dinge wie nscd, dnsmasq und andere Methoden, um die Auswirkungen lokaler Rekursorprobleme zu minimieren und die Belastung ihrer Rekursoren zu reduzieren. Die Merkmale im Betriebssystem variieren je nach Release-Version, Caching-Dämonen, Version der Caching-Daemons usw.

[Bearbeiten] Um dies zu wiederholen, ist dies kein normales Verhalten eines Recursers oder Caching-Daemons. Ich werde die fehlerhaften nicht beschämen, aber einer von ihnen wird als nicht gepflegt betrachtet, obwohl er mit vielen Linux Distributionen gebündelt ist.

Anwendungs-DNS-Cache

Einige Browser cachen auch Datensätze. Java und andere Apps cachen auch DNS. Sie können manchmal die maximale TTL in Anwendungen begrenzen.

Endeergebnisse können verzerrt sein

Die obigen Punkte können ein 15-minütiges TTL leicht in 60+ Minuten oder sogar noch länger verwandeln.

Aus diesem Grund schlage ich häufig vor, dass Anwendungen oder Websites mehrere aktive Knoten in ihrem Fehlertoleranzdesign berücksichtigen sollten, damit der Client schneller feststellen kann, wenn ein Einstiegspunkt in Ihre Site fehlgeschlagen ist, und das Problem automatisch in einem vernünftigen und vorhersehbaren Zustand behandelt wenn machbar. Anycast ist eine Methode, die einige Unternehmen verwenden, um Failover etwas transparent zu machen und sich nicht so sehr auf DNS-Änderungen zu verlassen. Es gibt auch einige clevere Methoden zum Lastenausgleich, die in Javascript mit mehreren DNS-Einträgen durchgeführt werden können.


0
2017-07-05 22:09



Die TTL wird nicht zurückgesetzt, nur weil der Datensatz von einem DNS-Server zum nächsten gesendet wird. Eine 15-minütige TTL bedeutet 15 Minuten, egal wie viele Schichten von Caches es durchläuft. Der einzige Weg, wie es mehr werden könnte, ist, wenn ein Teil der Software fehlerhaft ist und DNS nicht korrekt implementiert. - kasperd
Genau. Ich habe ein paar Buggy-Rekursoren gefunden. - Aaron


Alte Frage, aber neue Antworten (2017, 6 Jahre später):

  1. Scheint wie fast alle weltweiten DNS-Server in 5 Minuten zu aktualisieren
  2. Mit Google und OpenDNS können Sie einen DNS-Datensatz manuell leeren und die Weitergabe von Updates beschleunigen

Vor den Experimenten unten hatte ich vorher meine TTL von 14400 (Sekunden = 4 Stunden) auf 300 (Sekunden = 5 Minuten) geändert, aber ich machte das 2 Stunden vor den Experimenten und da die vorherige TTL 4 Stunden betrug, bin ich mir meiner Veränderung nicht sicher wäre herausgekommen, wenn DNS-Server nicht ihre eigene minimale TTL gehabt hätten.

Meine Experimente:

Experiment 1:

Ich habe eine Namens-zu-IP-Übersetzung (A-Datensatz) im autorisierenden Server geändert und dann Folgendes überprüft:

Nach 5 Minuten (300 Sekunden) war etwa die Hälfte der globalen Server, die von diesen Sites überprüft wurden, angepasst worden.

Nach 7 Minuten waren alle außer 1 aktualisiert worden.

Experiment 2:

Mit Google und OpenDNS können Sie den DNS-Cache für eine bestimmte Domain manuell leeren. Links:

Ich aktualisierte einen weiteren A-Datensatz und löschte sofort den DNS-Cache von Google. Sie haben ein Captcha, das mich dreimal "auf alle Quadrate mit Zeichen klicken" ließ, also dauerte es 1-2 Minuten, bevor ich den Flush abschließen konnte.

Nach 4 Minuten hatte nur 1 DNS-Server, der von diesen Sites überprüft wurde, die alte IP-Adresse. Alle anderen wurden aktualisiert.

Durch das Löschen des DNS-Caches von Google und das Erzwingen der erneuten Abfrage des autoritativen Servers scheint die globale DNS-Verbreitung beschleunigt worden zu sein, möglicherweise durch das Auslösen von Cache-Aktualisierungen auf den Servern weltweit.

Aber selbst ohne Google-Flush scheint die Verbreitung in Minuten statt in Stunden oder Tagen zu erfolgen.


-1
2017-07-05 21:50