Überwachen von DNS-Propagation nach einer Registrar-Änderung

DNS-Migrationen sehen auf dem Papier einfach aus, führen aber in der Praxis zu echten Problemen. Die Einträge werden beim Registrar aktualisiert, die TTLs verfallen, die Welt aktualisiert ihren DNS-Cache und alles funktioniert. Oder so geht die Geschichte. In Wirklichkeit tritt partielle Propagation regelmäßig auf: Einige Resolver liefern den neuen Eintrag, andere den alten, und das Benutzerverhalten spaltet sich entlang regionaler oder ISP-Grenzen auf. Dieses Handbuch behandelt, wie man eine DNS-Migration überwacht, was man überprüft und wie man die Fehler abfängt, die DNS nicht offenbart.

Wie DNS-Propagation tatsächlich funktioniert

Wenn Sie einen DNS-Eintrag beim Registrar ändern, bleibt der alte Eintrag in Resolver-Caches weltweit bestehen, bis seine TTL verfällt. Verschiedene Resolver aktualisieren sich zu unterschiedlichen Zeiten; einige respektieren die TTL streng, andere runden sie auf. Das Ergebnis ist ein Fenster (normalerweise eine TTL plus ein paar Minuten, aber manchmal Stunden), in dem verschiedene Benutzer unterschiedliche Einträge sehen.

Ihr eigener Resolver könnte der letzte sein, der sich aktualisiert, da Betriebssysteme und Anwendungen DNS oberhalb des OS-Level-Resolvers aggressiv zwischenspeichern. Der klassische Fehler ist, den neuen Endpunkt von Ihrem Laptop zu pingen, zu sehen, dass er funktioniert, die Migration als abgeschlossen zu erklären, und am nächsten Morgen festzustellen, dass EU-Kunden immer noch die alte IP treffen.

Was während einer Migration zu überwachen ist

Vier DNS-Eintragstypen decken die häufigen Migrationsfälle ab. Jeder benötigt seinen eigenen Monitor für die Dauer der Änderung.

• A- und AAAA-Einträge für den Hostnamen, den Sie migrieren. Die wichtigste Überprüfung: Wird die neue IP bereitgestellt?
• CNAME-Einträge für jede Subdomain, die einen verwendet. CNAME-Ketten können stillschweigend unterbrochen werden, wenn ein Link auf einen nicht existierenden Host verweist.
• MX-Einträge, wenn E-Mail beteiligt ist. Eine schlechte MX-Migration führt zu stiller E-Mail-Ablehnung ohne ein offensichtliches kundenorientiertes Symptom.
• NS-Einträge, wenn Sie DNS-Anbieter wechseln. Der NS-Eintrag ist die Grundlage; wenn er falsch ist, zählt nichts anderes.

Multi-Region-Überprüfung

Ein DNS-Monitor, der von einem einzelnen Resolver in einer einzelnen Region aus läuft, verfehlt völlig den Zweck. Die interessante Frage ist, ob sich der neue Eintrag überall propagiert hat, nicht ob der lokale Resolver Ihres Monitors aktualisiert wurde.

Tools wie dnschecker.org ermöglichen es Ihnen, die Propagation über mehrere Regionen interaktiv stichprobenartig zu überprüfen. Für automatisierte Überwachung benötigen Sie ein Tool, das mehrere Resolver überprüft und bei Abweichungen benachrichtigt. Wenn Ihr Überwachungstool nur von einem Ort aus überprüft, führen Sie eine zusätzliche manuelle Überprüfung von einer anderen Region durch (Ihr Telefon über Mobilfunkdaten ist oft ausreichend), bevor Sie die Migration als abgeschlossen erklären.

TTLs vor der Migration senken

Der wichtigste Vorbereitungsschritt ist, die TTL der betroffenen Einträge 24 bis 48 Stunden vor der Änderung zu senken. Die neue TTL muss sich zuerst propagieren, weshalb die Vorlaufzeit wichtig ist.

• Vor der Migration: TTL von der Standardeinstellung 3600 (1 Stunde) auf 60 (1 Minute) senken. Warten Sie, bis sich die TTL-Reduktion propagiert, was einen Zyklus der alten TTL plus einen Puffer dauert.
• Während der Migration: Eintrag aktualisieren. Resolver aktualisieren sich innerhalb von 60 Sekunden.
• Nach der Migration: 24 Stunden überwachen, um festgesteckte Caches abzufangen. TTL auf 3600 zurücksetzen, wenn Sie sich sicher sind, dass die Propagation abgeschlossen ist.

Den stillen Fehler der Teilpropagation abfangen

Teilpropagation ist der Ausfallmodus, der wehtut. Die Hälfte Ihrer Kunden sieht den neuen Endpunkt, die andere Hälfte sieht den alten, und dieser teilweise fehlerhafte Zustand ist für Ihre eigene Überwachung unsichtbar, wenn diese nur von einem Ort aus überprüft.

Drei Signale zeigen es an. Ein Anstieg in Support-Tickets, die das alte Verhalten oder den alten Hostnamen erwähnen. Eine Divergenz in Benutzermetriken zwischen Regionen (US-Konversion sinkt, während EU unverändert bleibt). Ein Monitor, der explizit die Resolver jeder Region separat prüft und bei Abweichungen warnt. Alle drei mindestens 24 Stunden lang nach einer Migration überwachen.

Prüfliste vor der Migration

Senken Sie zwei Tage vor der Migration die TTL aller betroffenen Datensätze auf 60 Sekunden. Am Tag davor fügen Sie DNS-Monitore für die neuen Datensatzwerte hinzu, die auslösen werden, da sich die Datensätze noch nicht geändert haben. Am Migrationstag aktualisieren Sie die Datensätze. Die Monitore schalten auf Grün. Überwachen Sie 24 Stunden lang und achten Sie auf Multi-Region-Abweichungen und das Volumen der Support-Tickets. Sobald beide 24 Stunden lang sauber sind, stellen Sie die TTLs wieder her und entfernen Sie die temporären Monitore. Die Migration ist abgeschlossen, wenn die Metriken sauber sind, nicht wenn die Datensätze aktualisiert werden.