Domain umziehen ohne Ausfall: Schritt für Schritt

Wer eine Domain umziehen will, ohne dass Website oder E-Mail ausfallen, trennt zwei Vorgänge: den Wechsel des Registrars per Auth-Code und den Umzug der DNS-Zone auf neue Nameserver. Zuerst wird die Zone beim neuen Anbieter vollständig nachgebaut und geprüft, erst danach werden die Nameserver umgestellt, und eine aktive DNSSEC-Signatur wird vorher sauber abgebaut. In dieser Reihenfolge bleibt die Domain während des gesamten Umzugs erreichbar.

Was bei einem Domain-Umzug eigentlich umzieht

Im Alltag steht "Domain umziehen" für drei verschiedene Dinge, die technisch nichts miteinander zu tun haben müssen:

Der Registrar: das Unternehmen, über das die Domain bei der Registry (etwa DENIC für .de) registriert ist und verlängert wird.
Das DNS-Hosting: die Nameserver, die auf Anfragen antworten und Einträge wie A, MX oder TXT ausliefern.
Die Dienste: Webserver, Postfächer, VPN-Gateways oder Cloud-Anwendungen, auf die diese Einträge zeigen.

Alle drei Ebenen können unabhängig voneinander wechseln. Sie können den Registrar wechseln und die alten Nameserver behalten, oder nur die Nameserver umstellen und beim bisherigen Registrar bleiben.

Ausfälle beim Domain-Umzug entstehen fast immer dann, wenn zwei Ebenen gleichzeitig wechseln und niemand vorher geprüft hat, ob die neue Zone vollständig ist. Wer die Ebenen nacheinander bewegt und nach jedem Schritt prüft, hat jederzeit einen funktionierenden Zustand, zu dem er zurückkehren kann.

Bestandsaufnahme: Was Sie vor dem Umzug klären müssen

Die meisten Probleme lassen sich lange vor dem eigentlichen Transfer erkennen. Gehen Sie diese Punkte schriftlich durch:

Ist Ihr Unternehmen als Inhaber eingetragen, oder steht dort noch eine Agentur oder ein ehemaliger Mitarbeiter?
Haben Sie Zugang zum Kundenkonto beim bisherigen Registrar, inklusive zweitem Faktor?
An welche E-Mail-Adresse gehen Bestätigungen? Liegt sie auf der Domain, die gerade umzieht, kann sie im entscheidenden Moment ausfallen.
Welche Laufzeit und Kündigungsfrist hat der bestehende Vertrag?
Ist die Domain Teil eines Pakets mit Postfächern oder Webspace, die bei Kündigung gelöscht werden?
Ist DNSSEC aktiv, und wer verwaltet die Schlüssel?
Ist eine Transfersperre gesetzt?

Wenn der Umzug Teil eines größeren Anbieterwechsels ist, hilft die Checkliste zum Thema IT-Dienstleister wechseln mit Verträgen, Zugängen und Übergabe, damit Zugangsdaten und Kündigungsfristen nicht zwischen den Beteiligten verloren gehen.

Die DNS-Zone vollständig erfassen

Fordern Sie beim bisherigen Anbieter einen Export der Zone an, idealerweise im Zonendatei-Format. Ein Zonentransfer per AXFR ist bei den meisten Anbietern aus guten Gründen gesperrt. Einzelne Einträge lassen sich zur Kontrolle mit dig abfragen:

for t in A AAAA MX TXT CAA NS SOA; do
  dig +noall +answer example.de $t
done
dig +noall +answer www.example.de A
dig +noall +answer _dmarc.example.de TXT
dig +noall +answer selector1._domainkey.example.de TXT
dig +noall +answer _autodiscover._tcp.example.de SRV

Subdomains lassen sich per DNS nicht auflisten, deshalb ersetzt diese Abfrage den Export nicht. Sie dient dazu, den Export gegenzuprüfen. Erfahrungsgemäß fehlen in selbst gepflegten Listen vor allem diese Einträge:

TXT-Einträge zur Verifizierung bei Cloud-Diensten und Suchmaschinen
DKIM-Schlüssel unter selektor._domainkey und der DMARC-Eintrag unter _dmarc
SRV- und CNAME-Einträge für Autodiscover, VoIP oder Kalender
CAA-Einträge, die festlegen, welche Zertifizierungsstellen Zertifikate ausstellen dürfen
Subdomains für VPN, Fernwartung oder Testsysteme, die nur intern bekannt sind

Domain umziehen in neun Schritten

Die folgende Reihenfolge funktioniert für einzelne Domains ebenso wie für einen Bestand von mehreren Dutzend:

TTL senken. Setzen Sie die TTL der wichtigsten Einträge mindestens 48 Stunden vor dem Umzug auf einen niedrigen Wert, etwa 300 Sekunden. Warum das wirkt und wo die Grenzen liegen, beschreibt der Beitrag zu TTL, sekundären Nameservern und einem sauberen DNS-Änderungsprozess.
Zone beim neuen Anbieter anlegen. Übernehmen Sie alle Einträge aus dem Export, ohne gleichzeitig Ziele zu ändern. Neue IP-Adressen oder Mailserver kommen später in einem eigenen Schritt.
Neue Zone direkt abfragen. Fragen Sie die neuen Nameserver gezielt ab und vergleichen Sie die Antworten mit den alten. Unterschiede klären Sie vor dem nächsten Schritt.
DNSSEC klären. Ist die Domain signiert, bauen Sie die Signatur wie im nächsten Abschnitt beschrieben ab, bevor sich an den Nameservern etwas ändert.
Transfersperre aufheben und Auth-Code anfordern. Der Auth-Code (bei .de AuthInfo genannt) ist das Passwort, mit dem der neue Registrar den Transfer beantragt.
Transfer beim neuen Registrar beauftragen. Geben Sie dabei zunächst die bisherigen Nameserver an. So ändert sich durch den Registrarwechsel nichts an der Auflösung.
Abschluss abwarten und prüfen. Kontrollieren Sie per WHOIS, dass der neue Registrar eingetragen ist und die Nameserver unverändert sind.
Nameserver umstellen. Erst jetzt tragen Sie die neuen Nameserver ein und prüfen, ob die übergeordnete Zone sie ausliefert.
Alte Zone weiterlaufen lassen, dann aufräumen. Lassen Sie die alte Zone mindestens zwei Tage unverändert bestehen, setzen Sie danach die TTL wieder hoch, aktivieren Sie DNSSEC beim neuen Anbieter und kündigen Sie erst dann den alten DNS-Dienst.

Für den Vergleich in Schritt 3 genügt ein kleines Skript, das dieselben Namen bei beiden Nameservern abfragt und die Ausgaben gegenüberstellt:

ALT=ns1.alter-anbieter.example
NEU=ns1.neuer-anbieter.example
for name in example.de www.example.de _dmarc.example.de; do
  for t in A AAAA MX TXT CAA CNAME; do
    a=$(dig +short @$ALT $name $t | sort)
    n=$(dig +short @$NEU $name $t | sort)
    [ "$a" != "$n" ] && echo "ABWEICHUNG $name $t"
  done
done

Nach Schritt 8 zeigt diese Abfrage, welche Nameserver die übergeordnete Zone tatsächlich ausliefert:

dig +trace +nodnssec example.de NS | tail -n 8

DNSSEC: die häufigste Ursache für Ausfälle beim Umzug

Bei einer signierten Domain liegt in der übergeordneten Zone ein DS-Eintrag, der auf den Schlüssel Ihres bisherigen DNS-Anbieters verweist. Validierende Resolver akzeptieren nur Antworten, die mit genau diesem Schlüssel signiert sind.

Wechseln Sie die Nameserver, während der alte DS-Eintrag noch gilt, signiert der neue Anbieter mit einem anderen Schlüssel oder gar nicht. Validierende Resolver antworten dann mit SERVFAIL. Das Tückische: Ein Teil der Nutzer erreicht Website und Mailserver weiterhin, ein anderer Teil nicht, je nachdem, welchen Resolver das jeweilige Netz verwendet. Die Fehlersuche dauert entsprechend lange.

Der sichere Weg für KMU ohne eigenes DNSSEC-Schlüsselmanagement:

Prüfen Sie, ob ein DS-Eintrag existiert und welche TTL er hat.
Lassen Sie den DS-Eintrag über den bisherigen Registrar entfernen. Die Zone bleibt vorerst signiert.
Warten Sie mindestens die TTL des DS-Eintrags ab, besser mit etwas Puffer.
Prüfen Sie, dass kein DS-Eintrag mehr ausgeliefert wird, und ziehen Sie erst dann Nameserver oder Registrar um.
Aktivieren Sie die Signatur beim neuen Anbieter und lassen Sie den neuen DS-Eintrag hinterlegen.

dig +noall +answer DS example.de
dig +dnssec +noall +answer example.de SOA
delv example.de A

Liefert delv die Meldung "fully validated", ist die Kette in Ordnung. Ein Validierungsfehler nach dem Umzug weist fast immer auf einen veralteten oder fehlenden DS-Eintrag hin. Es gibt auch Verfahren, bei denen beide Anbieter für eine Übergangszeit gemeinsam signieren. Sie setzen aber voraus, dass beide Seiten Schlüssel austauschen können, und sind für einen einfachen Anbieterwechsel meist unnötig aufwendig.

Besonderheiten bei .de, .com und .eu

Der Ablauf ist überall ähnlich, die Details unterscheiden sich je nach Endung:

.de: Der bisherige Registrar erzeugt eine AuthInfo, die nur begrenzte Zeit gültig ist. Fordern Sie sie deshalb erst an, wenn die neue Zone geprüft ist. Eine Wartefrist nach Registrierung gibt es bei .de nicht.
.com, .net, .org: Der Status clientTransferProhibited muss vor dem Transfer aufgehoben werden. Nach einer Registrierung oder einem vorherigen Transfer ist ein erneuter Wechsel in der Regel 60 Tage lang gesperrt. Ändern Sie Inhaberdaten nicht kurz vor dem Transfer, weil auch das eine solche Sperre auslösen kann. Der Transfer kann einige Tage dauern, und die Laufzeit verlängert sich dabei üblicherweise um ein Jahr.
.eu: Auch hier ist ein Auth-Code nötig, den der bisherige Registrar ausstellt. Inhaber müssen die Voraussetzungen für .eu weiterhin erfüllen.

Den Sperrstatus generischer Endungen sehen Sie direkt in der WHOIS-Ausgabe:

whois example.com | grep -i status

Typische Fehler und woran Sie sie erkennen

E-Mail fällt Tage nach dem Umzug aus: Das alte Paket wurde gekündigt, und mit ihm wurden Postfächer gelöscht, auf die der MX-Eintrag noch zeigte. Klären Sie vor der Kündigung, wohin die Postfächer umziehen, etwa zu einem E-Mail-Hosting auf eigener Domain mit Migration der Ordnerstruktur.
Transfer hängt: Die Bestätigungsmail ging an eine Adresse, die niemand mehr liest. Prüfen Sie die hinterlegten Kontakte vorab.
Zertifikatserneuerung schlägt fehl: Ein CAA-Eintrag wurde nicht übernommen oder erlaubt die neue Zertifizierungsstelle nicht.
Cloud-Dienst meldet die Domain als nicht verifiziert: Ein TXT-Eintrag fehlt in der neuen Zone.
Website ist nur für manche Nutzer erreichbar: Meist DNSSEC oder noch gecachte alte Einträge. Bei der systematischen Eingrenzung hilft die Anleitung Website nicht erreichbar: Ursache von DNS bis Webserver finden.

Selbst umziehen oder begleiten lassen?

Eine einzelne Domain mit Website und wenigen Einträgen lässt sich mit der obigen Anleitung gut selbst umziehen. Planungsaufwand entsteht vor allem bei vielen Domains, bei aktivem DNSSEC, bei E-Mail-Diensten mit DKIM und DMARC oder wenn mehrere Dienstleister beteiligt sind, die sich abstimmen müssen.

Wenn Sie den Umzug nicht selbst koordinieren möchten, ist ein begleiteter Transfer eine Möglichkeit. NETARO bietet unter Domains und DNS die Registrierung gängiger Endungen wie .de, .com und .eu, redundante Nameserver mit aktivem DNSSEC sowie einen begleiteten Transfer ohne Ausfall an. Unabhängig vom Anbieter gilt: Bestehen Sie auf einer geprüften Zone vor dem Nameserver-Wechsel und auf einer geklärten DNSSEC-Strategie.

FAQ

Wie lange dauert es, eine Domain umzuziehen?

Der eigentliche Registrarwechsel ist bei .de meist schnell erledigt, bei generischen Endungen wie .com kann er einige Tage dauern. Rechnen Sie für die Vorbereitung mit TTL-Senkung und gegebenenfalls DNSSEC-Abbau zusätzlich einige Tage ein. Die Umstellung der Nameserver selbst ist nach Ablauf der jeweiligen TTL wirksam.

Ist die Domain während des Transfers erreichbar?

Ja, wenn Sie beim Transfer die bisherigen Nameserver beibehalten und die alte Zone aktiv bleibt. Der Registrarwechsel ändert dann nichts an der Namensauflösung. Ausfälle entstehen erst, wenn gleichzeitig unvollständige Nameserver eingetragen werden oder ein veralteter DS-Eintrag bestehen bleibt.

Wo bekomme ich den Auth-Code für meine Domain?

Den Auth-Code stellt der bisherige Registrar aus, meist im Kundenkonto oder auf Anfrage beim Support. Bei .de heißt er AuthInfo und ist zeitlich begrenzt gültig. Behandeln Sie ihn wie ein Passwort, denn wer ihn kennt, kann den Transfer beantragen.

Kann ich meine E-Mails beim alten Anbieter behalten, wenn ich die Domain umziehe?

Ja, technisch ist das problemlos möglich. Übernehmen Sie dazu MX-, SPF-, DKIM- und DMARC-Einträge unverändert in die neue Zone und kündigen Sie beim alten Anbieter nur die Domain, nicht das Postfachpaket. Prüfen Sie vorher im Vertrag, ob Postfächer ohne zugehörige Domain dort weiterbetrieben werden.

Domain umziehen ohne Ausfall: Auth-Code, DNS-Zone und DNSSEC in der richtigen Reihenfolge