So prüfen Sie, ob eine DNS-Migration gelungen ist

Eine DNS-Migration – der Wechsel des Anbieters, der Umstieg auf ein neues Nameserver-Setup oder die Umstrukturierung einer großen Menge von Records – birgt mehr Risiko als die meisten Infrastrukturänderungen, gerade weil ein Fehler nicht laut auffällt. Ein defekter Record löst sich einfach stillschweigend nicht mehr auf oder wird zu etwas Falschem aufgelöst, und das erste Anzeichen ist oft ein Support-Ticket statt eines Alarms.

Vor der Migration

• Exportieren Sie jeden vorhandenen Record vom aktuellen Anbieter – eine vollständige Zonendatei oder ein Äquivalent, nicht nur die Records, an deren Konfiguration Sie sich erinnern.
• Senken Sie die TTLs der Records, die sich ändern werden, mindestens einen vollen TTL-Zyklus im Voraus.
• Notieren Sie die aktuellen Werte für alles: A/AAAA, CNAME, MX, TXT (einschließlich SPF/DKIM/DMARC) und alle weniger gebräuchlichen Record-Typen, die im Einsatz sind.

Nach der Migration

1. Fragen Sie die neuen autoritativen Nameserver direkt nach jedem migrierten Record ab und vergleichen Sie jede Antwort mit Ihrem Export vor der Migration.
2. Prüfen Sie A und AAAA unabhängig voneinander für jeden Hostnamen, der zuvor einen von beiden hatte – man migriert leicht eine Adressfamilie und vergisst die andere.
3. Verifizieren Sie gezielt MX und die zugehörigen Records zur E-Mail-Authentifizierung – ein E-Mail-Ausfall nach einer DNS-Migration kommt überproportional häufig vor und ist überproportional störend.
4. Prüfen Sie erneut über mehr als einen Resolver und idealerweise von mehr als einem Netzwerkstandort, bevor Sie die Migration für abgeschlossen erklären.
5. Warten Sie das alte TTL-Fenster ab und prüfen Sie dann nochmals – ein sauberes Ergebnis unmittelbar nach dem Cutover garantiert nicht, dass jeder gecachte Resolver weltweit schon nachgezogen hat.

Ein Massen-Lookup über die vollständige Hostnamen-Liste, einmal direkt nach dem Cutover und nochmals nach Ablauf des alten TTL-Fensters ausgeführt, macht aus einer manuellen Prüfung pro Record einen einzigen wiederholbaren Schritt – und liefert einen exportierbaren Nachweis darüber, was genau wann verifiziert wurde.

Die alte Seite nicht zu früh abbauen

Was man nach einer Migration am häufigsten bereut, ist nicht ein übersehener Record – sondern dass das Konto oder die Nameserver des alten Anbieters noch am selben Tag gekündigt oder außer Betrieb genommen wurden, an dem die neuen live gehen. Da ein Teil der Resolver weltweit bis zum Ablauf ihrer TTL noch mit gecachten Antworten arbeitet, die auf das alte Setup zeigen, ist es eine günstige Versicherung, den bisherigen Anbieter (auch wenn nichts Neues auf ihn zeigt) mindestens ein volles altes TTL-Fenster nach dem Cutover aktiv zu halten. Falls doch ein schneller Rollback nötig wird, entscheidet eine noch antwortende alte Seite darüber, ob Sie die Nameserver in Minuten zurückstellen oder unter Druck eine Zonendatei aus dem Gedächtnis rekonstruieren müssen.

Ein Probelauf fängt die meisten Probleme ab, bevor sie real werden

Wenn der neue DNS-Anbieter es erlaubt, bauen Sie die gesamte neue Zone vorab auf – vollständig konfiguriert, aber noch nicht delegiert – und fragen Sie sie direkt ab (an der normalen Delegierung vorbei, indem Sie ein Testwerkzeug explizit auf ihre Nameserver richten oder die Vorschaufunktion des Anbieters nutzen). So wird aus der Migrationsprüfung nach dem Cutover eine Prüfung davor – ohne Auswirkung auf Nutzer, falls etwas nicht stimmt. Jeder fehlende, falsch konfigurierte oder schlicht vom Beabsichtigten abweichende Record zeigt sich, bevor ihn ein einziger echter Resolver je gesehen hat – ein spürbar stressärmerer Zeitpunkt, um einen Fehler zu finden, als nachdem der Cutover bereits live gegangen ist.