Fenix von Takeda11
Viele Menschen sind verwirrt über die Aktualisierung von DNS-Einträgen, wenn sie die IP-Adresse ihrer Site ändern. Warum werden diese Datensätze langsam aktualisiert? Müssen Sie wirklich zwei Tage warten, bis alles aktualisiert ist? Warum sehen einige Besucher die neue IP, während andere die alte sehen?
Das Mail.ru Cloud Solutions- Team hateinen Artikel der Entwicklerin und Autorin von Artikeln, Julia Evans, übersetzt, in dem siediese Fragen beantwortet und im Volksmund erklärt, was während eines DNS-Updates aus Frontend-Sicht geschieht.
Hier finden Sie eine kurze Übersicht darüber, was hinter den Kulissen passiert, wenn Sie einen DNS-Eintrag aktualisieren.
Funktionsweise von DNS: Rekursive und autorisierende DNS-Server
Zunächst müssen wir ein wenig über das DNS-System erklären. Es gibt zwei Arten von DNS-Servern: autorisierende und rekursive .
Autorisierende DNS-Server (auch als Nameserver bezeichnet ) verwalten eine Datenbank mit IP-Adressen für jede Domäne, für die sie verantwortlich sind. Derzeit ist beispielsweise der autorisierende DNS-Server für github.com
ns-421.awsdns-52.com. Sie können ihn mit dieser Anfrage nach der IP-Adresse von github.com fragen:
dig @ns-421.awsdns-52.com github.com
Rekursive DNS-Server selbst wissen nichts darüber, wem welche IP-Adresse gehört. Sie berechnen die IP-Adresse für eine Domain, indem sie sie von den entsprechenden autorisierenden DNS-Servern abfragen und diese IP-Adresse zwischenspeichern, falls sie erneut danach gefragt werden. 8.8.8.8 ist also ein rekursiver DNS-Server.
Wenn Personen Ihre Website besuchen, führen sie wahrscheinlich DNS-Suchvorgänge auf einem rekursiven DNS-Server durch. Wie funktionieren rekursive DNS-Server? Werfen wir einen Blick darauf!
Wie ein rekursiver DNS-Server die IP-Adresse von github.com abfragt
Sehen wir uns ein Beispiel dafür an, was ein rekursiver DNS-Server (z. B. 8.8.8.8) tut, wenn Sie ihn nach der IP-Adresse (einem Eintrag) für github.com fragen. Wenn es bereits ein zwischengespeichertes Ergebnis hat, wird es zuerst ausgegeben. Was aber, wenn alle Caches abgelaufen sind? Hier ist was los ist.
Schritt 1 : Die IP-Adressen für die Root-DNS-Server sind im Quellcode fest codiert. Sie können dies im ungebundenen Quellcode sehen . Nehmen wir an, er wählt zuerst 198.41.0.4 aus. Hier ist die offizielle Quelle für diese fest codierten IP-Adressen, auch als "Root-Hints-Datei" bekannt.
Schritt 2 : Fragen Sie Root-Nameserver nach github.com.
Wir können ungefähr reproduzieren, was mit dem Befehl passiert
dig... Es gibt uns einen neuen autorisierenden Nameserver zum Anfordern: einen Nameserver für .commit einer IP-Adresse von 192.5.6.30.
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
Die Details der DNS-Antwort sind etwas komplizierter. In diesem Fall gibt es einen Berechtigungsabschnitt mit einigen NS-Einträgen und einen zusätzlichen Abschnitt mit A-Einträgen, sodass Sie keine zusätzliche Suche durchführen müssen, um die IP-Adressen dieser Nameserver abzurufen.
In der Praxis gibt es in 99,99% der Fälle bereits eine zwischengespeicherte Nameserver-Adresse
.com, aber wir tun so, als würden wir wirklich von vorne anfangen.
Schritt 3 : Fragen Sie Nameserver
.comnach github.com.
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
Wir haben eine neue IP-Adresse, um die Anfrage zu senden! Dies ist einer der Nameserver für github.com.
Schritt 4 : Fragen Sie die Nameserver von github.com nach der Adresse von github.com.
Wir sind fast fertig!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Wir haben also einen A-Rekord für github.com. Der rekursive Server hat jetzt die IP-Adresse github.com und kann diese an Sie zurückgeben. Und er konnte den gesamten Prozess durchlaufen, beginnend mit nur wenigen fest codierten IP-Adressen: den Adressen der Root-Nameserver.
So zeigen Sie alle Schritte eines rekursiven DNS-Servers an: dig + trace
Um zu sehen, wie der rekursive DNS-Server die Domäne auflöst, können Sie Folgendes ausführen:
$ dig @8.8.8.8 +trace github.com
Dieser Befehl zeigt alle DNS-Einträge an, die der rekursive Server anfordert, beginnend mit den DNS-Stammservern. Dies sind alle vier Schritte, die wir gerade durchlaufen haben.
DNS-Einträge aktualisieren
Nachdem wir die Grundlagen der Funktionsweise von DNS kennen, aktualisieren wir einige DNS-Einträge und sehen, was passiert.
Beim Aktualisieren von DNS-Einträgen gibt es zwei Hauptoptionen:
- Behalten Sie die gleichen Nameserver bei.
- Nameserver ändern.
Sprechen wir über TTL
Aber wir haben etwas Wichtiges vergessen. Das ist TTL. Wie bereits erwähnt, speichert ein rekursiver DNS-Server Einträge zwischen, bis sie ablaufen. Es entscheidet über den Ablauf eines Datensatzes basierend auf seiner TTL (Time to Live).
In diesem Beispiel gibt der GitHub-Nameserver eine TTL von 60 für seinen DNS-Eintrag zurück, was 60 Sekunden bedeutet:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Dies ist eine ziemlich kurze TTL. Wenn alle DNS-Implementierungen dem DNS-Standard folgen würden, würde dies theoretisch bedeuten, dass jeder innerhalb von 60 Sekunden eine neue IP-Adresse erhalten würde, wenn GitHub die IP-Adresse für github.com ändern würde. Mal sehen, wie das in der Praxis passiert.
Option 1: Aktualisieren Sie den DNS-Eintrag auf denselben Nameservern
Zuerst habe ich meine Nameserver (Cloudflare) aktualisiert, um einen neuen DNS-
test.jvns.caEintrag zu erhalten, den A- Eintrag , der 1.2.3.4 zugeordnet ist:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
Es hat sofort funktioniert! Es war überhaupt nicht nötig zu warten, da zuvor kein DNS-
test.jvns.caEintrag zwischengespeichert werden konnte. Ausgezeichnet. Es sieht jedoch so aus, als würde der neue Datensatz etwa fünf Minuten (299 Sekunden) zwischengespeichert.
Was ist, wenn wir versuchen, diese IP-Adresse zu ändern? Ich habe es in 5.6.7.8 geändert und dann dieselbe DNS-Abfrage ausgeführt:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
Es sieht so aus, als ob auf diesem DNS-Server der 1.2.3.4-Eintrag noch 144 Sekunden zwischengespeichert ist. Interessanterweise erhalten Sie bei mehrmaliger Abfrage von 8.8.8.8 widersprüchliche Ergebnisse - manchmal erhalten Sie eine neue und manchmal eine alte IP. Wahrscheinlich verteilt 8.8.8.8 die Last tatsächlich auf eine Reihe verschiedener Backends mit jeweils eigenem Cache.
Nach fünf Minuten Wartezeit wurden alle 8.8.8.8-Caches aktualisiert und es wurde immer ein neuer 5.6.7.8-Eintrag zurückgegeben. Tolle. Es ist ziemlich schnell!
Sie können sich nicht immer auf TTL verlassen
Wie bei den meisten Internetprotokollen folgt nicht alles der DNS-Spezifikation. Einige ISP-DNS-Server speichern Einträge länger als die angegebene TTL zwischen. Zum Beispiel innerhalb von zwei Tagen statt fünf Minuten. Und die Leute können immer die alte IP-Adresse in ihrer Datei fest codieren
/etc/hosts.
In der Praxis können Sie beim Aktualisieren eines DNS-Eintrags mit einer fünfminütigen TTL davon ausgehen, dass ein großer Prozentsatz der Clients schnell auf neue IP-Adressen migriert (z. B. innerhalb von 15 Minuten). In den nächsten Tagen wird eine Reihe von Nachzüglern langsam aktualisiert.
Option 2: Aktualisieren Ihrer Nameserver
Wir haben also festgestellt, dass viele DNS-Server ziemlich schnell eine neue IP-Adresse erhalten, wenn Sie eine IP-Adresse aktualisieren, ohne Ihre Nameserver zu ändern. Ausgezeichnet. Aber was passiert, wenn Sie Ihre Nameserver ändern? Lass es uns versuchen!
Ich wollte die Nameserver für mein Blog nicht aktualisieren, also habe ich stattdessen eine andere Domain von mir genommen und sie in den Beispielen für das HTTP- Protokoll examplecat.com verwendet.
Zuvor waren meine Server auf eingestellt
dns1.p01.nsone.net. Ich habe beschlossen, sie in Google-Server mit Adressen ns-cloud-b1.googledomains.comusw. zu ändern .
Als ich die Änderung vorgenommen habe, hat mein Domain-Registrar die Meldung etwas bedrohlich geflasht: „Änderungen an examplecat.com wurden gespeichert. Sie werden innerhalb der nächsten 48 Stunden in Kraft treten. " Dann habe ich einen neuen A-Eintrag für die Domain eingerichtet, der auf 1.2.3.4 verweist.
Okay, mal sehen, ob sich etwas geändert hat:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
Keine Änderungen. Wenn ich einen anderen DNS-Server frage, kennt er die neue IP:
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
Aber 8.8.8.8 weiß immer noch nichts. Der Grund, warum 1.1.1.1 eine neue IP sieht, obwohl ich sie erst vor fünf Minuten geändert habe, liegt wahrscheinlich darin, dass noch nie jemand 1.1.1.1 nach diesem examplecat.com gefragt hat - es hat also nichts im Cache Es war.
Nameserver haben viel mehr TTL
Der Grund, warum mein Registrar sagte: "Dies dauert 48 Stunden", ist, dass die TTL in den NS-Datensätzen (auf welchen Nameserver der rekursive Server zugreifen soll) viel größer ist.
Der neue Nameserver gibt definitiv eine neue IP-Adresse für examplecat.com zurück:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
Aber denken Sie daran, was passiert ist, als wir zuvor die Nameserver von github.com abgefragt haben:
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
172.800 Sekunden sind 48 Stunden! Daher dauert das Aktualisieren des Nameservers normalerweise viel länger. Es dauert einige Zeit, bis die Caches ablaufen und die neue Adresse weitergegeben wird. Es dauert viel länger, als nur Ihre IP-Adresse zu aktualisieren, ohne Ihren Nameserver zu ändern.
Wie Ihre Nameserver aktualisiert werden
Wenn ich Nameserver für aktualisiere
examplecat.com, .comerhält der Nameserver einen neuen NS-Eintrag mit einer neuen Domäne. So was:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
Aber wie kommt dieser neue NS-Rekord dorthin? Tatsächlich sage ich meinem Domain-Registrar, wie die neuen Nameserver aussehen sollen, indem ich sie auf der Website aktualisiere, und dann weist mein Domain-Registrar die Nameserver
.coman, das Update durchzuführen.
Für
.comdiesen Updates sind ziemlich schnell (innerhalb weniger Minuten), aber ich denke , dass für einige andere TLD - Zonen, kann nicht die Name - Server - Updates so schnell anzuwenden.
Die DNS-Resolver-Bibliothek Ihres Programms kann auch DNS-Einträge zwischenspeichern
Ein weiterer Grund, warum die TTL in der Praxis möglicherweise nicht beachtet wird, besteht darin, dass viele Programme DNS-Namen auflösen müssen und einige Programme DNS-Einträge im Speicher auf unbestimmte Zeit zwischenspeichern (bis das Programm neu gestartet wird).
Beispielsweise gibt es einen Artikel zum Konfigurieren von JVM-TTL für die Suche nach DNS-Namen . Ich habe selbst nicht viel JVM-Code für DNS-Suchvorgänge geschrieben, aber eine kleine Internetsuche über JVM und DNS erweckt den Eindruck, dass Sie die JVM so konfigurieren können, dass jede DNS-Suche unendlich lange zwischengespeichert wird (siehe beispielsweise dieses ElasticSearch-Ticket ). ...
Das ist alles!
Ich hoffe, dies hilft Ihnen zu verstehen, was passiert, wenn Sie Ihr DNS aktualisieren.
Ich werde reservieren, dass der gesamte Verlauf der DNS-Verteilung nicht nur von TTL bestimmt wird. Einige rekursive DNS-Server respektieren TTLs wahrscheinlich nicht, selbst große Server wie 8.8.8.8. Selbst wenn Sie den A-Datensatz nur mit einer kleinen TTL aktualisieren, ist es in der Praxis möglich, dass Sie innerhalb von ein oder zwei Tagen immer noch Anforderungen für die alte IP erhalten.
Nach dem Posten dieses Artikels habe ich die Nameserver für examplecat.com wieder auf ihre alten Werte zurückgesetzt.
Was noch zu lesen: