DNS-Umzug ohne Ausfall: TTL richtig planen

Was die TTL ist und warum sie den Umzug bestimmt

Jeder DNS-Record trägt eine TTL (Time to Live) in Sekunden. Sie sagt Resolvern wie denen von Google, Cloudflare oder der Telekom, wie lange sie die Antwort zwischenspeichern dürfen, ohne erneut beim autoritativen Nameserver zu fragen. Bei einer TTL von 86400 kann ein Resolver deinen alten A-Record bis zu 24 Stunden nach der Änderung weiter ausliefern, und du kannst nichts dagegen tun.

Genau deshalb beginnt ein Umzug nicht mit der Änderung, sondern mit der TTL. Senkst du sie rechtzeitig auf 300 Sekunden, laufen alte Caches spätestens fünf Minuten nach der Umschaltung aus. Der Haken: Die Senkung muss selbst erst durch die alte TTL hindurch. Wer heute von 86400 auf 300 geht, muss 24 Stunden warten, bis alle Resolver den neuen Wert kennen.

Zwei Arten von Umzug

Ein Hosting-Umzug ändert nur einzelne Records, meist A, AAAA und vielleicht CNAME für www. Die Zone bleibt beim selben DNS-Anbieter. Das ist der einfache Fall: TTL senken, warten, Record ändern, fertig.

Ein Nameserver-Wechsel ist etwas anderes. Hier zieht die komplette Zone zu einem anderen Anbieter, und die NS-Records am Registrar werden umgestellt. Die TTL der NS-Delegation bei der Registry (bei .de zum Beispiel) kannst du nicht beeinflussen, sie liegt oft bei einem Tag oder länger. Deshalb müssen alte und neue Zone während der Übergangszeit identisch sein, denn du weißt nie, welchen Nameserver ein Resolver gerade fragt.

Schritt für Schritt: Nameserver wechseln

Die Reihenfolge ist entscheidend. Jeder Schritt, den du überspringst, taucht später als Ausfall wieder auf.

1. 24 bis 48 Stunden vorher: TTL aller Records in der alten Zone auf 300 senken.
2. Die komplette alte Zone exportieren oder abschreiben: A, AAAA, CNAME, MX, alle TXT (SPF, DKIM-Selektoren, DMARC unter _dmarc, Verifizierungsrecords von Google, Microsoft und anderen), SRV, CAA, und jede einzelne Subdomain.
3. Alles beim neuen Anbieter anlegen, mit denselben Werten und ebenfalls kurzer TTL.
4. Die neue Zone direkt gegen die neuen Nameserver prüfen, bevor irgendetwas umgeschaltet wird (siehe unten). Der DNS Checker vergleicht beide Zonen Record für Record.
5. Falls DNSSEC aktiv ist: DS-Record am Registrar entfernen oder auf die neuen Schlüssel umstellen, sonst SERVFAIL nach dem Wechsel.
6. NS-Records am Registrar auf die neuen Nameserver setzen.
7. Nach dem Wechsel Website, Mailempfang, Mailversand und alle Subdomains testen.
8. Nach ein bis zwei Tagen TTL wieder auf 3600 oder höher setzen.

Die klassischen Fehler

Fast jeder Ausfall bei einem DNS-Umzug hat eine dieser Ursachen, und fast alle wären beim Vergleich der Zonen vor der Umschaltung aufgefallen.

• MX vergessen: Die Website läuft, aber keine Mail kommt mehr an. Absender bekommen Bounces oder ihre Mails hängen in Warteschlangen.
• DKIM-Selektoren vergessen: Der Versand läuft weiter, aber jede Mail scheitert an DKIM und damit oft an DMARC. Das fällt erst auf, wenn Mails im Spam landen.
• SPF kopiert, aber Verifizierungs-TXT-Records nicht: Google Workspace oder Microsoft 365 melden die Domain irgendwann als nicht mehr verifiziert.
• DS-Record am Registrar vergessen: Die alten DNSSEC-Schlüssel sind noch hinterlegt, die neue Zone ist anders signiert oder gar nicht. Validierende Resolver liefern SERVFAIL, die Domain ist für einen Großteil der Nutzer weg.
• Subdomains übersehen: shop., api., intranet., autodiscover. und Wildcard-Records tauchen im Panel des alten Anbieters oft erst nach Scrollen auf.
• CAA vergessen oder falsch übernommen: Die nächste Zertifikatserneuerung schlägt fehl.

Propagation richtig prüfen

Wer nach der Umschaltung mit nslookup oder dig ohne Angabe eines Servers prüft, fragt seinen eigenen Resolver, und der liefert bis zum Ablauf der TTL die alte Antwort. Das sagt nichts darüber aus, ob die neue Zone richtig ist. Frag stattdessen die autoritativen Nameserver direkt, alte und neue, und vergleiche.

# Neue Zone direkt beim neuen Nameserver prüfen, vor dem Wechsel
dig @ns1.neuer-anbieter.de beispiel.de MX +short
dig @ns1.neuer-anbieter.de beispiel.de TXT +short
dig @ns1.neuer-anbieter.de selektor1._domainkey.beispiel.de TXT +short

# Welche Nameserver sieht die Welt?
dig beispiel.de NS +short

# Delegation bei der Registry prüfen
dig @a.nic.de beispiel.de NS

Erst wenn die Antworten beider Nameserver für jeden Record übereinstimmen, ist die Umschaltung sicher. Nach dem Wechsel zeigt eine Abfrage bei mehreren öffentlichen Resolvern (8.8.8.8, 1.1.1.1, 9.9.9.9), wie weit die Propagation ist.

Nach dem Umzug

Lass die alte Zone mindestens eine Woche unverändert weiterlaufen. Resolver mit langen Caches, Mailserver, die die NS-Records noch von gestern kennen, und Registry-TTLs sorgen dafür, dass ein Teil der Anfragen noch Tage später bei den alten Nameservern ankommt. Solange dort dieselben Daten liegen, merkt niemand etwas.

Danach die TTL wieder anheben. 3600 Sekunden sind ein guter Standard, für Records, die sich nie ändern, auch 86400. Kurze TTLs erhöhen die Zahl der Anfragen und machen die Domain anfälliger, wenn ein Nameserver ausfällt. Und mach eine Momentaufnahme der fertigen Zone, damit du beim nächsten Mal weißt, wie sie aussehen soll.

Häufige Fragen

Wie lange dauert die Propagation wirklich?

So lange wie die längste beteiligte TTL. Bei gesenkten Record-TTLs und einem reinen Hosting-Umzug wenige Minuten. Bei einem Nameserver-Wechsel bestimmt die TTL der Registry-Delegation, meist zwischen einigen Stunden und zwei Tagen. Solange alte und neue Zone identisch sind, ist das egal.

Kann ich die TTL auf 60 Sekunden setzen?

Technisch ja, und für die Stunden rund um die Umschaltung ist das in Ordnung. Manche Resolver ignorieren sehr kurze TTLs und cachen trotzdem einige Minuten. Dauerhaft sind 60 Sekunden aber unnötig und erzeugen viele Anfragen.

Muss ich DNSSEC beim Umzug abschalten?

Am sichersten ist es, den DS-Record am Registrar vor dem Wechsel zu entfernen, zu warten, bis er aus den Caches verschwunden ist, und DNSSEC beim neuen Anbieter danach neu zu aktivieren. Ein Wechsel mit durchgehender Signierung ist möglich, erfordert aber, dass beide Anbieter die Schlüssel abstimmen.