Nameserver wechseln ohne Ausfall: Schritt-für-Schritt-Plan

Ein Nameserver-Wechsel gehört zu den wenigen DNS-Vorgängen, die eine ganze Domain vom Netz nehmen können: Website, E-Mail, API, alles. Schief geht es selten wegen der Umstellung selbst. Es geht schief, weil die neue Zone unvollständig war, weil eine TTL eine Woche lang war oder weil DNSSEC noch auf den alten Anbieter zeigte.

Dieser Leitfaden ist der Plan, dem wir selbst folgen würden. Die Beispiele verwenden reservierte Namen und Dokumentationsadressen.

Was beim Nameserver-Wechsel tatsächlich passiert

Ihre Domain hat NS-Records an zwei Stellen:

In der Elternzone (der Registry für .com, .org, .com.tr …). Das ist die Delegation. Sie ändern sie bei Ihrem Registrar.
In Ihrer eigenen Zone, ausgeliefert von Ihrem DNS-Anbieter. Diese sollten mit der Delegation übereinstimmen.

Braucht ein Resolver www.example.com und hat nichts im Cache, fragt er die Elternzone, wer zuständig ist, bekommt die Delegation und fragt dann einen dieser Nameserver. Nameserver wechseln heißt, die Delegation in der Elternzone zu ändern.

Nichts wird „ins Internet geschoben“. Resolver auf der ganzen Welt verwenden weiter, was sie im Cache haben, bis es abläuft; dann fragen sie erneut und bekommen die neue Antwort. Deshalb spricht man von „Propagation“, und deshalb ist das Wort irreführend: Es gibt keine Welle, die sich ausbreitet, nur Caches, die zu unterschiedlichen Zeiten ablaufen.

Schritt 1: Bestandsaufnahme der alten Zone

Exportieren Sie die vollständige Zone beim alten Anbieter. Gibt es eine Exportfunktion (BIND-Format), verwenden Sie sie. Wenn nicht, listen Sie jeden Record von Hand auf. Die Records, die gern vergessen werden:

MX sowie die TXT-Records für SPF, DKIM-Selektoren (selector._domainkey) und _dmarc
TXT-Records zur Verifizierung für Search Consoles, SaaS-Tools und die Ausstellung von Zertifikaten
CAA-Records
SRV-Records (_sip, _autodiscover, _matrix …)
Subdomains, die mit eigenen NS-Records anderswohin delegiert sind
Wildcard-Records (*.example.com)

Eine öffentliche Abfrage zeigt nur die Namen, nach denen Sie fragen, und kann den Export daher nicht ersetzen. Als Gegenprobe ist sie trotzdem nützlich:

$ dig +short example.com MX
10 mx1.mail.example.
$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Schritt 2: Neue Zone aufbauen und direkt testen

Legen Sie jeden Record beim neuen Anbieter an, bevor Sie die Delegation anfassen. Fragen Sie dann die neuen Nameserver direkt ab, an den Caches vorbei, und vergleichen Sie mit den alten:

$ dig @ns1.olddns.example example.com A +short
192.0.2.10
$ dig @ns1.newdns.example example.com A +short
192.0.2.10

Wiederholen Sie das für jeden Record-Typ und jeden Hostnamen aus Ihrer Bestandsaufnahme. Die Antworten müssen exakt übereinstimmen, es sei denn, Sie ändern absichtlich etwas. Widerstehen Sie der Versuchung, den Nameserver-Wechsel mit einem Serverumzug zu verbinden: Ändern Sie eine Sache auf einmal, damit ein Problem nur eine mögliche Ursache hat.

Schritt 3: TTLs vorab absenken

Zwei TTLs sind entscheidend:

Die TTLs Ihrer Records beim alten Anbieter. Senken Sie sie (300 Sekunden sind üblich) mindestens eine alte TTL vor dem Umzug. War die alte TTL 86400, tun Sie das einen Tag oder mehr im Voraus.
Die TTL der Delegation in der Elternzone. Diese kontrollieren Sie nicht. Bei vielen TLDs beträgt sie 48 Stunden (172800 Sekunden). Das ist die tatsächliche Länge Ihres Migrationsfensters.

Wegen des zweiten Punkts sollten Sie einplanen, dass beide Nameserver-Sets mindestens zwei bis drei Tage lang korrekt antworten.

Schritt 4: DNSSEC zuerst behandeln

Ist die Domain signiert, hält die Elternzone einen DS-Record, der auf den Schlüssel des alten Anbieters zeigt. Wechseln Sie die Nameserver, während dieser DS noch steht, und signiert der neue Anbieter mit einem anderen Schlüssel (oder gar nicht), behandeln validierende Resolver jede Antwort als bogus. Die Domain wird für einen großen Teil der Nutzer dunkel, und abgesenkte TTLs retten Sie nicht.

Prüfen Sie zuerst:

$ dig +short example.com DS

Gibt es einen DS-Record, wählen Sie einen der beiden Wege:

Während des Umzugs unsigniert bleiben. Entfernen Sie den DS beim Registrar, warten Sie, bis die DS-TTL der Elternzone abgelaufen ist (oft 24 Stunden oder mehr), wechseln Sie die Nameserver, aktivieren Sie DNSSEC dann beim neuen Anbieter und veröffentlichen Sie den neuen DS.
Eine Multi-Signer-Migration durchführen, wenn beide Anbieter das unterstützen: Jeder Anbieter veröffentlicht vor der Umstellung den öffentlichen Schlüssel des anderen. So bleibt die Domain durchgehend signiert, aber es braucht die Mitwirkung beider Seiten.

Schritt 5: Delegation umstellen

Ersetzen Sie beim Registrar die alten Nameserver durch das neue Set. Tragen Sie sie genau so ein, wie der neue Anbieter sie angibt. Manche Registries führen technische Prüfungen durch und lehnen eine Änderung ab, wenn die neuen Server für die Zone nicht autoritativ antworten; ein Grund mehr, Schritt 2 vorher abzuschließen.

Lassen Sie die alte Zone laufen, unverändert. In den nächsten Tagen fragen manche Resolver noch die alten Server. Müssen Sie in diesem Fenster einen Record ändern, ändern Sie ihn an beiden Stellen.

Schritt 6: Von mehreren Orten aus prüfen

Prüfen Sie die Sicht der Elternzone direkt:

$ dig +trace example.com NS

Fragen Sie dann mehrere öffentliche Resolver und vergleichen Sie. Rechnen Sie eine Weile mit gemischten Antworten. Das ist normal und bedeutet nicht, dass etwas kaputt ist, solange beide Zonen dieselben Daten ausliefern.

Worauf Sie achten sollten:

Welches NS-Set liefert jeder Standort: das alte oder das neue? Ein gemischtes Set (einer alt, einer neu) ist kein Erfolg.
Stimmen die Antworten für A, AAAA und MX zwischen alt und neu überein?
Liefert HTTPS weiterhin ein gültiges Zertifikat, und kommt E-Mail weiterhin an?

Seien Sie vorsichtig mit Aussagen wie „zu 85 % propagiert“. Kein Werkzeug kann jeden Resolver im Internet messen. Eine ehrliche Aussage ist enger gefasst: „9 von 12 überwachten Standorten liefern die neuen Nameserver, 2 liefern noch die alten, 1 konnte nicht geprüft werden.“

Schritt 7: Vorsichtig außer Betrieb nehmen

Warten Sie mindestens die Delegations-TTL der Elternzone plus einen Sicherheitspuffer (drei Tage sind ein vernünftiges Minimum, eine Woche ist bequem), bevor Sie die alte Zone löschen. Setzen Sie dann die TTLs Ihrer Records wieder auf normale Werte (3600 oder mehr), um die Abfragelast zu senken und die Ausfallsicherheit zu erhöhen.

Plan für den Rückweg

Notieren Sie sich vor dem Start die Namen der alten Nameserver und lassen Sie die alte Zone unangetastet. Stimmt nach der Umstellung etwas nicht:

Beheben Sie den Record beim neuen Anbieter, wenn das Problem ein fehlender oder falscher Record ist. Das ist fast immer die schnellste Lösung.
Fällt der neue Anbieter selbst aus, setzen Sie die Delegation auf die alten Nameserver zurück. Bedenken Sie, dass der Rückweg demselben Caching unterliegt und ebenfalls nicht sofort wirkt.

Häufige Fehler

Zuerst umstellen und die Records danach neu anlegen.
DKIM-Selektoren vergessen, sodass E-Mails Tage später an DMARC scheitern.
Einen DS-Record stehen lassen, wenn Sie zu einem Anbieter wechseln, der nicht mit demselben Schlüssel signiert.
Die alte Zone noch am selben Tag löschen.
Eine einzige erfolgreiche Abfrage vom eigenen Laptop als Beweis dafür nehmen, dass der Umzug abgeschlossen ist.

Mit OrbitProbe prüfen

Mit der DNS-Abfrage sehen Sie die Records und Nameserver, die öffentliche Resolver für Ihre Domain gerade zurückgeben, und mit der Whois-Abfrage bestätigen Sie die Nameserver und den DNSSEC-Status, die bei der Registry hinterlegt sind. Im OrbitProbe-Workspace können Sie außerdem eine Überwachung für genau das Nameserver-Set anlegen, das Sie erwarten; sie meldet, wie viele überwachte Standorte übereinstimmen, welche noch den alten Wert zeigen und welche nicht geprüft werden konnten. Was mit einer TTL im Einzelnen geschieht, erklärt der Beitrag Was ist die TTL im DNS, und die Grundlagen zu DNSSEC stehen in DNSSEC erklärt.