DNS-Verbreitung prüfen

Vergleichen Sie, was mehrere öffentliche Resolver für denselben Record antworten, um zu sehen, ob eine Änderung angekommen ist.

Abgefragt werden Cloudflare, Google, Quad9 und Control D vom Server von IPGet aus; jede Antwort wird einzeln ausgewiesen.

Was tatsächlich geprüft wird

Die Abfrage geht vom Server von IPGet an vier bestimmte öffentliche Resolver, und die Antwort jedes einzelnen wird getrennt gezeigt: Cloudflare unter 1.1.1.1, Google unter 8.8.8.8, Quad9 unter 9.9.9.9 und Control D unter 76.76.2.0. Das ist keine weltweite Messung und keine Abdeckung aller existierenden Resolver, sondern sind vier bekannte Blickwinkel.

Sie getrennt zu zeigen statt zu einem Urteil zusammenzufassen, ist Absicht, denn gerade die Abweichung ist die nützliche Information. Wissenswert ist außerdem: Quad9 filtert Domains, die es für schädlich hält — ein dort gesperrter Name kann nichts zurückgeben und bei den anderen drei völlig normal auflösen, und das ist kein Verbreitungsfehler.

Verbreitung ist keine Reise

Das Bild einer DNS-Änderung, die „um die Welt wandert“, führt in die Irre. Es wird nichts irgendwohin gesendet: Jeder Resolver behält die frühere Antwort, bis ihre TTL abläuft, und fragt erst dann die autoritativen Server erneut. Der Unterschied zwischen Resolvern während einer Änderung ist keine Entfernung, sondern ein Zwischenspeicher mit unterschiedlichen Uhren.

Daraus folgt das Praktische: Senken Sie die TTL des Records im Voraus — Stunden oder Tage vor der Änderung, nicht im Moment der Änderung — damit alte Kopien schnell verfallen. Nach der Änderung beträgt die längste Wartezeit ungefähr die vorherige TTL. Liefert ein Resolver danach immer noch den alten Wert, liegt das Problem wahrscheinlich nicht am Zwischenspeicher, sondern an der Zone selbst.

Wie die Unterschiede zu deuten sind

Stimmen alle Resolver mit dem erwarteten Wert überein, ist die Änderung aus diesen vier Blickwinkeln abgeschlossen. Liefern einige den neuen und andere den alten Wert, läuft die Änderung noch und es hilft nur Warten. Liefern alle nach Ablauf der vorherigen TTL noch den alten Wert, prüfen Sie, ob die Änderung wirklich in der richtigen Zone gespeichert wurde.

Ein einzelner Resolver mit Fehler bei antwortenden übrigen deutet meist auf eine vorübergehende Störung dieses Dienstes hin und nicht auf Ihre Domain. Antwortet keiner, liegt die Ursache meist bei den autoritativen Servern; prüfen Sie dort die NS-Records und den Status der Domain.