Wie lange dauert die Verbreitung von DNS-Einträgen?

Dies ist eine kanonische Frage zur DNS-Weitergabe

Wie lange dauert es, bis sich die verschiedenen Arten von Datensätzen verbreiten?
Breiten sich manche schneller aus als andere?
Warum dauert es eine Weile, bis sich DNS-Einträge verbreiten und wie funktioniert es?

"DNS-Verbreitung" ist an sich kein echtes Phänomen. Es ist vielmehr der offensichtliche Effekt der im DNS-Protokoll angegebenen Caching-Funktionalität. Zu behaupten, dass sich Änderungen zwischen DNS-Servern "verbreiten", ist eine bequeme Lüge, die für nicht-technische Benutzer wahrscheinlich einfacher zu erklären ist, als alle Details des DNS-Protokolls zu beschreiben. Es ist jedoch nicht wirklich so, wie das Protokoll funktioniert.

Rekursive DNS-Server stellen Abfragen im Namen von Clients. Rekursive DNS-Server, die normalerweise von ISPs oder IT-Abteilungen ausgeführt werden, werden von Clientcomputern zum Auflösen von Namen von Internetressourcen verwendet. Rekursive DNS-Server speichern die Ergebnisse von Abfragen im Cache, um die Effizienz zu verbessern. Abfragen für bereits zwischengespeicherte Informationen können ohne zusätzliche Abfragen beantwortet werden. Die Dauer in Sekunden, für die ein Ergebnis zwischengespeichert wird, soll auf einem konfigurierbaren Wert basieren, der als Time To Live (TTL) bezeichnet wird. Dieser Wert wird vom autorisierenden DNS-Server für den abgefragten Datensatz angegeben.

Es gibt keine Antwort auf alle gestellten Fragen, da DNS ein verteiltes Protokoll ist. Das Verhalten von DNS hängt von der Konfiguration des autorisierenden DNS-Servers für einen bestimmten Datensatz, der Konfiguration rekursiver DNS-Server, die Abfragen für Clientcomputer durchführen, und der in die Betriebssysteme der Clientcomputer integrierten DNS-Caching-Funktionalität ab.

Es ist empfehlenswert, einen TTL-Wert anzugeben, der kurz genug ist, um die täglichen Änderungen an DNS-Einträgen zu berücksichtigen, aber lang genug, um einen "Gewinn" beim Zwischenspeichern zu erzielen (dh nicht zu kurz, um den Cache zu schnell zu veralten) Verbesserung der Effizienz). Die Anwendung einer ausgewogenen Strategie mit TTL-Werten führt zu einem "Gewinn" für alle. Dies reduziert sowohl die Auslastung als auch die Bandbreitennutzung für die autorisierenden DNS-Server für eine bestimmte Domäne, die Stammserver und die TLD-Server. Dies verringert die Auslastung der Upstream-Bandbreite für den Betreiber des rekursiven DNS-Servers. Dies führt zu schnelleren Abfrageantworten für Clientcomputer.

Wenn die TTL eines DNS-Eintrags festgelegt ist, steigt die Auslastung und die Bandbreitennutzung auf den autorisierenden DNS-Servern, da rekursive DNS-Server das Ergebnis über einen längeren Zeitraum nicht zwischenspeichern können. Da die TTL eines Datensatzes höher ist, werden Änderungen an Datensätzen nicht schnell "wirksam", da Clientcomputer weiterhin zwischengespeicherte Ergebnisse empfangen, die auf ihren rekursiven DNS-Servern gespeichert sind. Das Einstellen der optimalen TTL ist ein Spagat zwischen Auslastung und der Fähigkeit, Datensätze schnell zu ändern und diese Änderungen auf den Clients zu sehen.

Es ist anzumerken, dass einige ISPs missbräuchlich sind und die von den autorisierenden DNS-Servern angegebenen TTL-Werte ignorieren (wobei sie ihre eigene administrative Überschreibung ersetzen, was eine Verletzung von RFC darstellt). In technischer Hinsicht gibt es nichts zu tun. Wenn die Betreiber missbräuchlicher DNS-Server ausfindig gemacht werden, führen Beschwerden bei ihren Systemadministratoren möglicherweise dazu, dass sie Best Practices implementieren (was für jeden mit DNS vertrauten Netzwerktechniker möglicherweise vernünftig ist). Diese Art von Missbrauch ist kein technisches Problem.

Wenn jeder „nach den Regeln spielt“ Änderungen an DNS - Einträge können „wirksam“ sehr schnell. Im Falle einer Änderung der IP-Adresse, die einem "A" -Datensatz zugewiesen ist, würde beispielsweise eine exponentielle Zurücksetzung des TTL-Werts durchgeführt, die zu dem Zeitpunkt führt, zu dem die Änderung vorgenommen wird. Die TTL kann beispielsweise an einem Tag beginnen und für einen Zeitraum von 24 Stunden auf 12 Stunden, dann für einen Zeitraum von 12 Stunden auf 6 Stunden, für einen Zeitraum von 6 Stunden auf 3 Stunden usw. bis zu einem angemessen kleinen Intervall verringert werden. Nach dem Zurücksetzen der TTL kann der Datensatz geändert und die TTL für den täglichen Betrieb wieder auf den gewünschten Wert gebracht werden. (Es ist nicht erforderlich, ein exponentielles Backoff zu verwenden. Diese Strategie minimiert jedoch die Zeit, in der der Datensatz eine niedrige TTL aufweist, und verringert die Belastung des autorisierenden DNS-Servers.)

Nach der Erstellung eines DNS-Eintrags sollten Änderungsprotokolle auf Zugriffsversuche aufgrund des alten DNS-Eintrags überwacht werden. In dem Beispiel, in dem ein "A" -Datensatz geändert wird, um auf eine neue IP-Adresse zu verweisen, sollte ein Server an der alten IP-Adresse vorhanden bleiben, um Zugriffsversuche zu verarbeiten, die von Clientcomputern ausgehen, die weiterhin den alten "A" -Datensatz verwenden. Sobald Zugriffsversuche, die auf dem alten Datensatz basieren, ein akzeptabel niedriges Niveau erreicht haben, kann die alte IP-Adresse nicht mehr verwendet werden. Wenn die Anforderungen in Bezug auf einen alten Datensatz nicht schnell nachlassen, ignoriert möglicherweise (wie oben beschrieben) ein rekursiver DNS-Server die autorisierende TTL. Die Kenntnis der Quell-IP-Adresse eines Zugriffsversuchs liefert jedoch keine direkten Informationen über den rekursiven DNS-Server, der für die Bereitstellung eines alten Datensatzes verantwortlich ist.

Persönlich habe ich gesehen, dass Änderungen sofort, in wenigen Stunden und in einigen Fällen bei einem bestimmten gehirngeschädigten ISP, nach mehreren Tagen "wirksam" werden. Wenn Sie Ihre TTL zurücknehmen und sich darüber im Klaren sind, wie der Prozess abläuft, werden sich Ihre Änderungen positiv auf den Erfolg auswirken. Sie können sich jedoch nicht sicher sein, was ein wohlmeinender Idiot mit seinen rekursiven DNS-Servern tun könnte.