DNS-Umzug ohne Ausfall: TTL, Reihenfolge, Checkliste

„Wir haben nur den Anbieter gewechselt – und jetzt kommen keine Mails mehr an.“ Fast immer ist die Ursache ein vergessener Eintrag oder ein falscher Zeitpunkt. Mit einer festen Reihenfolge lässt sich das vermeiden.

Drei Arten von „Umzug“

Im Alltag wird alles „Umzug“ genannt, technisch sind es drei verschiedene Vorgänge:

1. Hosting-Wechsel: Die Website bekommt eine neue IP-Adresse. Der DNS-Anbieter bleibt, es ändern sich A/AAAA-Einträge (und eventuell MX).

2. DNS-Anbieter-Wechsel: Die Nameserver der Domain wechseln. Die komplette Zone muss beim neuen Anbieter vorhanden sein, bevor die Delegation umgestellt wird.

3. Registrar-Wechsel (Domain-Transfer): Die Domain wird zu einem anderen Registrar übertragen. Die Nameserver können dabei unverändert bleiben.

Wer mehrere Vorgänge gleichzeitig durchführt, findet Fehler schwer wieder. Besser nacheinander und mit Abstand von einigen Tagen.

TTL früh senken

Die TTL (Time To Live) bestimmt, wie lange Resolver einen Eintrag zwischenspeichern. Steht sie auf 24 Stunden, liefern Resolver nach der Änderung bis zu einen Tag lang die alte IP aus.

Deshalb: Die TTL der betroffenen Einträge (A, AAAA, MX, CNAME) mindestens so lange vor dem Umzug senken, wie die alte TTL beträgt – zum Beispiel auf 300 Sekunden. Nach dem erfolgreichen Umzug wieder erhöhen.

Beim Wechsel der Nameserver gilt das nur eingeschränkt: Die Delegation (NS-Einträge bei der Registry der Top-Level-Domain) hat meist eine feste TTL von oft 24 Stunden oder mehr, die man nicht selbst senken kann. Alte und neue Nameserver sollten deshalb in dieser Zeit dieselben Antworten liefern.

Die Zone vollständig kopieren

Vor der Umstellung muss beim neuen Anbieter alles vorhanden sein, nicht nur die Website:

A/AAAA für Hauptdomain und www sowie alle Subdomains, MX-Einträge samt Prioritäten, TXT-Einträge (SPF, DKIM-Schlüssel, DMARC, Verifizierungen für Google, Microsoft, Search Console), CNAMEs (z. B. Autodiscover), SRV-Einträge und CAA-Einträge.

Besonders häufig vergessen werden TXT-Einträge für E-Mail-Authentifizierung. Die Folge sind Mails im Spam oder abgelehnte Nachrichten (siehe dazu auch den Artikel über SPF, DKIM und DMARC).

Einen Export liefert der alte Anbieter oft als Zonendatei. Wenn nicht, hilft eine Abfrage der wichtigsten Typen:

for t in A AAAA MX TXT CNAME NS CAA; do dig +noall +answer beispiel.de $t; done

Subdomains lassen sich so natürlich nicht aufzählen – dafür die Verwaltungsoberfläche des alten Anbieters öffnen und Eintrag für Eintrag abgleichen.

Vor der Umstellung testen

Neuer Webserver: Mit curl lässt sich ein Hostname testweise auf eine IP zwingen, ohne das DNS zu ändern:

curl -I --resolve beispiel.de:443:203.0.113.10 https://beispiel.de/

Neuer Nameserver: Die Zone direkt dort abfragen, bevor die Delegation geändert wird:

dig @ns1.neuer-anbieter.de beispiel.de A
dig @ns1.neuer-anbieter.de beispiel.de MX

Reihenfolge am Umzugstag

1. Daten final synchronisieren. Bei Shops, Foren und Formularen zuvor Schreibzugriffe kurz anhalten oder sofort vor der Umstellung noch einmal abgleichen, sonst gehen Bestellungen oder Beiträge verloren.

2. DNS umstellen (IP-Adresse oder Nameserver).

3. Die alte Umgebung noch 48 bis 72 Stunden weiterlaufen lassen. Resolver mit altem Cache landen sonst im Leeren.

4. E-Mail getrennt betrachten. Postfachinhalte wandern nicht mit dem DNS. Sie müssen separat übertragen werden (z. B. per IMAP-Sync). Erst wenn die neuen Postfächer gefüllt sind, den MX umstellen.

Nach dem Umzug prüfen

dig +trace beispiel.de
dig @1.1.1.1 beispiel.de A
dig @8.8.8.8 beispiel.de A

Verschiedene Resolver zeigen, wie weit sich die Änderung verbreitet hat. Außerdem prüfen: Funktioniert das TLS-Zertifikat? Bei Let's Encrypt (HTTP-01) muss Port 80 offen sein und jeder vorhandene AAAA-Eintrag auf den neuen Server zeigen. Funktionieren Weiterleitungen und www? Ein Test-Mail-Versand und -Empfang? Search Console und Monitoring auf Fehler geprüft?

Typische Fehler

Vergessener AAAA-Eintrag: IPv6-Nutzer landen weiter beim alten Server – und Let's Encrypt prüft bevorzugt per IPv6.

TTL nicht rechtzeitig gesenkt: Die Umstellung dauert dann einen Tag statt Minuten.

CAA-Eintrag erlaubt nur die bisherige Zertifizierungsstelle – das Zertifikat auf dem neuen Hosting kommt aber von einer anderen.

Subdomains und Spezialeinträge vergessen: autodiscover, mail, shop, Verifizierungs-TXT.

Alten Vertrag zu früh gekündigt: Während der Übergangszeit sollten beide Seiten erreichbar bleiben.

Checkliste

TTL mindestens eine alte TTL vor dem Umzug auf 300 Sekunden gesenkt?
Zone beim neuen Anbieter vollständig, inklusive MX, TXT, CAA, Subdomains?
Neuer Server und neue Nameserver vorab getestet?
Daten final synchronisiert, Schreibzugriff kurz eingefroren?
Alte Umgebung 48–72 Stunden weiter aktiv?
E-Mail-Postfächer separat migriert, danach MX umgestellt?
Nach dem Umzug: Resolver, Zertifikat, IPv6, Weiterleitungen, Test-Mail geprüft?
TTL wieder erhöht?

Ein sauberer Umzug ist weniger Hexerei als Disziplin: früh vorbereiten, vollständig kopieren, vor der Umstellung testen und danach geduldig prüfen.