Beim Hostingwechsel bleibt der Domainname häufig gleich, obwohl sich der Server ändert. Dafür muss die Namensauflösung zum richtigen Ziel führen. Ein Transfer der Domainverwaltung ist eine zusätzliche Entscheidung. Wer beide Aufgaben getrennt plant, kann die Website kontrolliert verlagern und vermeidet unnötige Änderungen an Mail oder anderen Diensten. Dieser Artikel erklärt den Prüfweg vom DNS-Inventar bis zur tatsächlichen HTTPS-Verbindung.
Drei Zuständigkeiten unter einem Domainnamen
Die Domainverwaltung legt unter anderem fest, welcher Provider den Namen betreut. Autoritative Nameserver liefern die maßgeblichen DNS-Antworten. Das Webhosting verarbeitet die Verbindung zu einer Website. Diese Aufgaben können bei derselben Firma liegen, müssen es aber nicht. Schreiben Sie auf, wer jede Rolle übernimmt und in welcher Oberfläche Änderungen erfolgen. Eine neue Adresse im Hostingpanel verändert nicht automatisch die DNS-Zone bei einem anderen DNS-Anbieter.
Für .de-Domains beschreibt DENIC einen Providerwechsel über AuthInfo. Der Wechselcode autorisiert die Verwaltungsübertragung und verdient denselben vertraulichen Umgang wie andere Zugangsdaten. Er kopiert keine WordPress-Dateien und ersetzt keinen Datenbankumzug. Prüfen Sie deshalb, ob Sie lediglich das Websiteziel ändern oder zusätzlich den Registrar wechseln wollen. Für andere Endungen gelten die Verfahren der jeweiligen Registry und beteiligten Registrare; die .de-Regeln sollten nicht ungeprüft übertragen werden.
Die bestehende Zone vollständig erfassen
Erstellen Sie vor Änderungen eine Bestandsliste der Domain und ihrer genutzten Subdomains. Notieren Sie Recordtyp, Name, Inhalt und TTL sowie den Zweck. Die Hauptdomain allein reicht nicht: www, ein Shop, ein Kundenbereich und technische Prüfsubdomains können unterschiedliche Ziele haben. Ein Zonenauszug ist hilfreich, sollte aber kontrolliert geschützt gespeichert werden, wenn er interne Bezeichnungen enthält. Vergleichen Sie den Auszug mit den wirklich genutzten Diensten, damit veraltete und aktive Einträge erkennbar werden.
Behandeln Sie Mail ausdrücklich als eigenen Bereich. MX-Einträge und mailbezogene TXT-Werte gehören nicht automatisch zur Websiteverlagerung. Auch Verifikationen externer Dienste können in TXT-Einträgen stehen. Wenn die Website zu einem neuen Server wechselt, ist ein pauschaler Austausch der gesamten Zone meist unnötig. Bei einem Nameserverwechsel müssen die benötigten Werte dagegen zuerst im neuen DNS-System vorhanden sein. Für diese Übernahme braucht es eine verantwortliche Person und eine Prüfung gegen den Bestand.
| Eintrag | Typischer Bezug | Prüffrage |
|---|---|---|
| A | IPv4-Ziel eines Namens | Ist dies die freigegebene IPv4-Adresse der Zielumgebung? |
| AAAA | IPv6-Ziel eines Namens | Erreicht natives IPv6 denselben richtigen Websitebestand? |
| CNAME | Verweis auf einen anderen Namen | Ist das verwiesene Ziel weiterhin passend? |
| MX | Mailzustellung | Bleibt der Maildienst unverändert zuständig? |
| TXT / CAA | Dienstverifikation oder Zertifikatregel | Welche Gegenstelle oder Richtlinie benötigt den Wert? |
Autoritative Antworten und Zwischenspeicher
Die DNS-Grundlagen in RFC 1034 unterscheiden Nameserver, Resolver und zwischengespeicherte Informationen. Für eine Umzugsprüfung bedeutet das: Eine Antwort aus dem lokalen Netz ist ein Beobachtungspunkt, aber nicht der einzige. Fragen Sie die zuständigen autoritativen Nameserver direkt ab und vergleichen Sie sie miteinander. Prüfen Sie anschließend, was normale Resolver sehen. Dadurch lassen sich ein fehlerhafter Zonenstand und eine noch vorhandene ältere Cacheantwort auseinanderhalten.
Die TTL steuert, wie lange ein Record zwischengespeichert werden darf. Eine rechtzeitig angepasste TTL kann die Übergangsplanung unterstützen. Sie löscht aber keine zuvor gespeicherten Antworten rückwirkend. Eine nach dem Wechsel verkürzte TTL beschleunigt die bereits vorhandene alte Cacheantwort nicht automatisch. Planen Sie deshalb den Wechsel vorab und vermeiden Sie die pauschale Zusage, nach einer festen Minutenzahl sähen garantiert alle Menschen denselben Server. Der praktische Prüfumfang sollte mehrere Netze und den fachlichen Dienst berücksichtigen.
Die neue Umgebung vor der Umschaltung prüfen
Das Zielhosting muss den Domainnamen bereits korrekt annehmen. Dazu gehören virtuelle Websitezuordnung, Anwendungskonfiguration und Zertifikat. Eine Standardseite unter der neuen IP-Adresse belegt lediglich, dass ein Webserver geantwortet hat. Sie sagt noch nichts darüber aus, ob der richtige Domainhost existiert. Prüfen Sie den tatsächlichen Hostnamen über einen geeigneten kontrollierten Testweg, bevor Sie öffentliche Einträge verändern. Die Wechselvorbereitung verbindet diesen Test mit der Datenkopie.
Wenn eine lokale Namenszuordnung zum Testen verwendet wird, gehört ihr Ende ebenfalls in den Plan. Nach der öffentlichen Umschaltung entfernen Sie diese Sonderzuordnung und testen die normale DNS-Auflösung erneut. Andernfalls könnte Ihr eigenes Gerät weiterhin einen Zielserver erreichen, während normale Besucher einen Fehler sehen. Dokumentieren Sie bei jeder wichtigen Prüfung, ob öffentliche Namensauflösung oder eine bewusste Zieladressierung verwendet wurde. Beide liefern nützliche, aber unterschiedliche Belege.
- DNS-Zone: gewünschtes Ziel
- Resolver: sichtbare Antwort
- Netzwerk: erreichbare Adresse
- TLS: passender Domainname
- Anwendung: richtige Website
IPv4 und IPv6 einzeln abnehmen
Ein korrekter A-Eintrag sagt nichts über einen vorhandenen AAAA-Eintrag aus. Ist eine alte IPv6-Adresse weiterhin veröffentlicht, können Besucher über IPv6 eine andere Installation erreichen. Prüfen Sie daher für Hauptdomain und www jeweils beide Recordtypen. Nutzen Sie die tatsächlichen Adressen aus dem neuen Hostingbestand. Eine in einem anderen Projekt dokumentierte Serveradresse ist keine ausreichende Grundlage für die neue Domain. Auch die Zuweisung im Panel und die Veröffentlichung im DNS sind getrennte Arbeitsschritte.
Zur Abnahme gehört eine echte Verbindung über jede veröffentlichte Adressfamilie. Eine IPv4-Adresse in einer IPv6-kompatiblen Darstellung beweist keine native IPv6-Verbindung. Falls der eigene Anschluss IPv6 nicht unterstützt, dokumentieren Sie die Testgrenze und nutzen einen geeigneten berechtigten Prüfpunkt. Entfernen Sie keine AAAA-Einträge aus bloßer Bequemlichkeit; klären Sie das vorgesehene Ziel mit den Verantwortlichen. Nach der Netzverbindung muss auch HTTPS mit korrekter Namensprüfung auf diesem Weg funktionieren.
Zertifikat und Weiterleitung gehören zum selben Wechsel
Prüfen Sie, welche Namen das Zertifikat abdeckt und welcher Name die Hauptadresse der Website ist. Hauptdomain und www können auf denselben Server zeigen, benötigen aber beim HTTPS-Aufruf passende Behandlung. Eine Weiterleitung von www auf die Hauptdomain erfolgt erst nach dem TLS-Verbindungsaufbau. Ein Zertifikatsfehler auf www lässt sich deshalb nicht durch eine später gedachte Weiterleitung reparieren. Der Ratgeber SSL-Zertifikat und HTTPS vertieft die Domain- und Erneuerungsprüfung.
Testen Sie die Weiterleitung mit einem vorhandenen Unterpfad und mit einer harmlosen Query. Wer nur die Startseite prüft, übersieht leicht, dass Links auf ältere Artikel oder Kampagnen nicht mehr korrekt ankommen. Bei gleichbleibenden URLs sollte das Ziel denselben fachlichen Inhalt liefern. Ändern sich URLs bewusst, benötigen Sie eine Zuordnung alter und neuer Adressen. Google dokumentiert Umzüge mit URL-Änderungen; diese sind umfassender als ein reiner Serverwechsel.
Nameserver und DNSSEC nur mit vorbereitetem Übergang
Ein Wechsel der autoritativen Nameserver verlagert die gesamte Verantwortung für die Zone. Bereiten Sie daher zunächst die neue Zone vor und prüfen Sie ihre Antworten direkt. Erst anschließend wird die Delegation geändert. Stellen Sie sicher, dass benötigte Subdomains und Mailwerte übernommen sind. Wenn DNSSEC verwendet wird, müssen Schlüssel- und Delegationsinformationen zum neuen Verfahren passen. Diese Aufgabe verdient einen eigenen kontrollierten Ablauf mit dem DNS-Anbieter; ein unkoordinierter Austausch kann die Auflösung für validierende Resolver beeinträchtigen.
Für eine kleine Website kann es organisatorisch einfacher sein, DNS zunächst beim bisherigen Dienst zu lassen und nur Websiteadressen zu ändern. Diese Option muss zum Vertrag und den verfügbaren Verwaltungsrechten passen. Entscheidend ist, dass der alte DNS-Dienst nach Kündigung des Webhostings weiter bestehen darf. Fragen Sie diesen Zusammenhang vorab nach. Ein funktionierender Eintrag am Umschalttag hilft wenig, wenn die gesamte Zone einige Tage später durch das Vertragsende entfernt wird.
Ein Beispiel mit getrenntem Maildienst
Eine Unternehmenswebsite verwendet die Hauptdomain und www, während Mail bei einem externen Anbieter liegt. Im Plan werden nur die Webziele verändert. Das Team prüft A und AAAA auf den zuständigen Nameservern, testet beide HTTPS-Namen und vergleicht den Websitebestand. MX und Mail-TXT-Werte werden gegen den vorher dokumentierten Zustand kontrolliert. Diese Kontrolle erkennt unbeabsichtigte Änderungen, ohne Mail selbst zu verlagern. Das Beispiel ist eine redaktionelle Planungsskizze und keine Behauptung über einen hier getesteten Anbieter.
Nach der Umschaltung meldet eine Mitarbeiterin eine alte Seite. Das Team fragt zunächst nach Adresse, Zeitpunkt und Netz statt erneut wahllos DNS zu ändern. Wenn autoritative Antworten bereits korrekt sind, wird die Resolverantwort des betroffenen Anschlusses geprüft. Zeigt dieser noch den alten Wert, erklärt das die unterschiedliche Sicht. Zeigt er den neuen Wert, muss die Diagnose in Richtung Cache, Hostzuordnung oder Anwendung weitergehen. So bleibt jede Änderung an eine nachvollziehbare Ursache gebunden.
Die Abschlussliste
Reservieren Sie für die Umschaltung einen Zeitpunkt, an dem sowohl Anwendung als auch DNS betreut werden können. Ein DNS-Verantwortlicher ohne Zugriff auf die Zielwebsite kann einen fehlerhaften Anwendungstest nicht allein korrigieren. Umgekehrt kann die Redaktion einen falschen AAAA-Eintrag nicht durch eine WordPress-Einstellung reparieren. Die beteiligten Personen sollten denselben freigegebenen Änderungsumfang kennen. Halten Sie den alten und neuen Wert im Änderungsprotokoll fest, damit auch eine begründete Rücknahme präzise möglich bleibt.
Vermeiden Sie mehrere unkoordinierte Bearbeiter derselben Zone. Wenn eine Person im Panel einen Wert korrigiert und eine andere gleichzeitig einen vorbereiteten Zonenauszug importiert, kann die zweite Aktion die erste überschreiben. Vereinbaren Sie daher einen einzigen aktiven Änderungsweg für das Zeitfenster. Andere Beteiligte liefern Prüfergebnisse und Änderungswünsche an diese Stelle. Nach dem Wechsel sollten die Berechtigungen wieder dem dauerhaften Betriebsmodell entsprechen und temporäre Zugänge aufgehoben werden.
Die Übergabe enthält schließlich eine verständliche Beschreibung der Hauptadresse. Schreiben Sie auf, welcher Name offiziell verwendet wird, welche Varianten weiterleiten und wo die DNS-Verwaltung künftig liegt. Das verhindert, dass eine spätere neue Subdomain in der falschen Oberfläche angelegt wird. Der Eintrag gehört zur Betriebsdokumentation der Website und sollte bei einem erneuten Providerwechsel aktualisiert werden. Gerade selten bearbeitete DNS-Einstellungen profitieren von einer kurzen, gut auffindbaren Notiz.
- Registrar, autoritative Nameserver und Hosting sind eindeutig zugeordnet.
- Die relevante Zone ist gesichert und mit genutzten Diensten abgeglichen.
- A und AAAA wurden für alle Webnamen separat geprüft.
- Die Zielwebsite antwortet mit richtigem Zertifikat und richtigem Inhalt.
- Weiterleitungen erhalten benötigte Pfade und Parameter.
- Unveränderte Mailwerte und externe Verifikationen wurden kontrolliert.
- Lokale Testzuordnungen wurden entfernt und der normale Zugriff wieder geprüft.
Bewahren Sie die Ergebnisse mit Zeitpunkten auf. Eine spätere Rückfrage lässt sich dann auf eine konkrete Prüfebene beziehen. Für die Tarifauswahl ist außerdem relevant, ob Sie DNS selbst bearbeiten können oder für Änderungen einen Supportauftrag benötigen. Diese Betriebsfrage gehört in den Hostingvergleich, besonders wenn häufig neue Subdomains oder externe Dienste angebunden werden. Ein guter Wechselplan macht Zuständigkeit und Nachweis genauso sichtbar wie die neue Serveradresse.