Du migrierst eine Website, bei dir sieht alles gut aus, und dann kommen plötzlich die ersten Meldungen rein. Manche Besucher sehen die neue Website, andere landen immer noch auf der alten, und ein paar melden Fehler, die du überhaupt nicht nachvollziehen kannst.
Wenn das passiert, ist es leicht, dem Host oder der Migration selbst die Schuld zu geben. Meistens liegt die eigentliche Ursache jedoch beim DNS (nicht, weil es kaputt ist, sondern weil es genau das tut, wofür es entwickelt wurde).
DNS-Aktualisierungen erfolgen nicht auf einmal. Sie sind von Caching-Ebenen und Resolvern außerhalb deiner Hosting-Umgebung abhängig, weshalb Migrationen sich unvorhersehbar anfühlen können, selbst wenn die Website bereit ist.
Dieser Leitfaden erklärt, was das DNS tatsächlich steuert, warum sich die Propagierung bei verschiedenen Nutzern unterschiedlich verhält und wie du eine Migration so planst, dass das DNS ein kontrollierter letzter Schritt ist, statt eine Quelle für Ausfallzeiten oder Verwirrung.
Was DNS eigentlich macht
DNS beantwortet eine ganz bestimmte Frage: Wohin soll diese Domain verweisen?
Wenn jemand deine Domain in einen Browser eingibt, übersetzt das DNS diesen Namen in eine IP-Adresse. Diese IP-Adresse teilt dem Browser mit, mit welchem Server er sich verbinden soll. Das DNS lädt keine Seiten und kümmert sich nicht darum, was auf dem Server läuft. Es kümmert sich lediglich um die Suche.
Damit diese Suche zuverlässig funktioniert, ist das DNS in mehrere separate Komponenten unterteilt, von denen jede eine klare Rolle hat.
- Domain-Registrar: Bei deinem Registrar wird die Domain gekauft und verlängert. Er hostet deine Website nicht und steuert auch nicht den Datenverkehr. Aus DNS-Sicht besteht seine Hauptaufgabe darin, die Domain auf die richtigen Nameserver zu verweisen.
- Autoritativer DNS-Anbieter: Dies ist der Dienst, der deine DNS-Einträge speichert und die endgültige Antwort liefert, wenn das Internet fragt, wohin deine Domain aufgelöst werden soll. Anbieter wie Cloudflare oder deine Hosting-Plattform übernehmen oft diese Rolle.
- Nameserver: Nameserver teilen dem Internet mit, welcher DNS-Anbieter für deine Domain autoritativ ist. Sie enthalten selbst keine Website-Daten oder Konfigurationen. Sie leiten DNS-Anfragen einfach an die richtige Stelle weiter.
- DNS-Einträge (A, AAAA, CNAME): Diese Einträge legen fest, wohin der Datenverkehr geleitet wird. A-Einträge verweisen eine Domain auf eine IPv4-Adresse, AAAA-Einträge auf eine IPv6-Adresse und CNAME-Einträge verweisen eine Domain auf eine andere.
Zusammen entscheiden diese Einträge, welchen Server Besucher erreichen, wenn sie deine Website laden.
Genauso wichtig ist, was DNS nicht tut. DNS stellt keine Dateien bereit, verschiebt keine Datenbanken, synchronisiert keine Inhalte und verwaltet keine SSL-Zertifikate. Es greift niemals in deine Hosting-Umgebung ein.
Sobald diese Grenze klar ist, lässt sich der Rest des Migrationsprozesses viel einfacher nachvollziehen.
Was sich bei einer Website-Migration ändert und was gleich bleibt
Ein Grund, warum DNS bei Migrationen so viel Verwirrung stiftet, ist, dass sich tatsächlich nur ein kleiner Teil der Konfiguration ändert. Der Rest bleibt genau so, wie er vorher war, auch wenn die Website selbst vielleicht in eine völlig neue Umgebung umzieht.
Bei einer typischen Website-Migration ändern sich normalerweise ein paar Dinge.
- Die IP-Adresse ändert sich fast immer, da die Website nun auf einem anderen Server läuft. Dies ist die häufigste DNS-bezogene Aktualisierung und diejenige, die dem Datenverkehr letztendlich mitteilt, wohin er geleitet werden soll.
- Auch die Hosting-Umgebung ändert sich. Dazu gehören der Server, die Infrastruktur und die Plattform, auf der deine Website läuft. Das wirkt sich zwar auf Leistung und Stabilität aus, ist aber unabhängig vom DNS und sollte vollständig bereit sein, bevor irgendwelche DNS-Aktualisierungen erfolgen.
- In vielen Fällen ändern sich bestimmte DNS-Einträge. A-Einträge oder AAAA-Einträge werden aktualisiert, um auf die neue IP-Adresse zu verweisen. Manchmal werden stattdessen CNAME-Einträge angepasst, je nachdem, wie die Website konfiguriert ist.
Gleichzeitig bleiben einige Dinge in der Regel unverändert.
- Der Domainname ändert sich nicht. Besucher geben weiterhin dieselbe URL ein, und an der öffentlich zugänglichen Adresse muss nichts aktualisiert werden.
- Auch die Nameserver bleiben gleich, es sei denn, du wechselst bewusst den DNS-Anbieter. Bei den meisten Migrationen ist überhaupt keine Änderung der Nameserver erforderlich, selbst wenn der Hosting-Anbieter wechselt.
Deshalb ist DNS fast immer der letzte Schritt bei einer Migration. Du richtest zuerst die neue Umgebung ein und überprüfst sie, dann aktualisierst du das DNS, sobald alles bereit ist, Datenverkehr zu empfangen.
Wenn du DNS als letzten Schritt statt als frühe Aufgabe behandelst, verringert das Unsicherheiten, begrenzt Risiken und macht es viel einfacher, Ausfallzeiten zu vermeiden.
DNS-Propagierung und warum sie unvorhersehbar ist
DNS-Propagierung bedeutet nicht, dass das Internet deine Domain auf einen Schlag „aktualisiert“. Es beschreibt, wie lange es dauert, bis DNS-Änderungen von vielen unabhängigen Systemen übernommen, zwischengespeichert und wiederverwendet werden.
Wenn jemand deine Website besucht, geht seine Anfrage nicht jedes Mal direkt an deinen DNS-Anbieter. Sie durchläuft in der Regel einen rekursiven Resolver, der oft von einem ISP, einem Unternehmensnetzwerk oder einem öffentlichen Dienst wie Google oder Cloudflare betrieben wird. Dieser Resolver fragt den autoritativen DNS-Anbieter nach einer Antwort und speichert das Ergebnis dann für die spätere Verwendung.
Sobald ein Resolver eine DNS-Antwort zwischenspeichert, verwendet er diese Antwort so lange, bis der Cache abläuft. Hier kommt die Unvorhersehbarkeit ins Spiel. Verschiedene Resolver speichern DNS-Daten für unterschiedliche Zeiträume im Cache. Einige halten sich genau an die TTL-Werte. Andere wenden ihre eigenen Grenzen an oder verwenden zwischengespeicherte Daten länger als erwartet.
Zudem können Browser- und Betriebssystem-Caches DNS-Ergebnisse lokal speichern. Selbst wenn der globale DNS-Eintrag aktualisiert wurde, verwendet das Gerät eines Nutzers möglicherweise weiterhin eine ältere Antwort, bis der lokale Cache geleert wird oder abläuft.
Dieses mehrschichtige Caching erklärt, warum zwei Personen an verschiedenen Orten zur gleichen Zeit unterschiedliche Versionen derselben Website sehen können. Ein Resolver hat die neue IP-Adresse. Ein anderer verweist noch auf den alten Server.
Die gängige „24–48-Stunden“-Regel vereinfacht das tatsächliche Geschehen zu sehr. Viele Nutzer sehen Aktualisierungen innerhalb von Minuten. Andere sehen sie möglicherweise erst viel später, je nachdem, wie sich ihr Resolver und ihre lokalen Caches verhalten.
TTL und wie es hilft, Ausfallzeiten zu vermeiden
TTL, oder Time to Live, steuert, wie lange DNS-Antworten zwischengespeichert werden, bevor ein Resolver neue Informationen anfordert. Es zwingt keine schnelleren Aktualisierungen, sondern begrenzt, wie lange veraltete Informationen wiederverwendet werden können.
Jeder DNS-Eintrag hat seinen eigenen TTL-Wert, gemessen in Sekunden. Wenn ein Eintrag eine TTL von 300 hat, können Resolver diese Antwort bis zu fünf Minuten lang wiederverwenden, bevor sie erneut nachfragen. Ein TTL-Wert von 86.400 ermöglicht eine Zwischenspeicherung für einen ganzen Tag.
Deshalb ist es wichtig, den TTL-Wert vor einer Migration zu senken. Wenn Resolver bereits kurzlebige DNS-Antworten vorhalten, aktualisieren sie diese häufiger, wenn du Einträge änderst. Das verringert das Zeitfenster, in dem Besucher nach der Umstellung möglicherweise noch auf den alten Server weitergeleitet werden.
Bei den meisten Migrationen bietet eine TTL zwischen 300 und 600 Sekunden einen guten Mittelweg. Sie ist kurz genug, um Verzögerungen bei der Weiterleitung zu begrenzen, ohne die DNS-Infrastruktur unnötig zu belasten.
Eine zu niedrige Einstellung kann Probleme verursachen. Extrem kurze TTLs garantieren keine sofortigen Aktualisierungen, und manche Resolver ignorieren ungewöhnlich kleine Werte. Andere begrenzen möglicherweise die Anzahl der Anfragen oder greifen ohnehin auf zwischengespeicherte Daten zurück. Das Senken der TTL in letzter Minute ist ein weiterer häufiger Fehler. Wenn Caches bereits langlebige Einträge enthalten, wirkt sich eine Änderung der TTL erst aus, wenn diese Caches ablaufen.
Der sicherste Ansatz ist das richtige Timing. Reduziere die TTL mindestens 24 Stunden vor der Migration, vergewissere dich, dass der neue Wert live ist, und plane erst dann die DNS-Änderung.
Ein sicherer Zeitplan für die DNS-Migration (Schritt für Schritt)
Bei einer reibungslosen DNS-Migration hat die Reihenfolge Vorrang vor der Geschwindigkeit. Wenn jeder Schritt in der richtigen Reihenfolge erfolgt, wird die DNS-Umstellung zu einem kontrollierten Vorgang statt zu einem Ratespiel. So gehst du erfolgreich vor:
1. Bereite die neue Hosting-Umgebung vor
Richte die neue Website vollständig ein, bevor du dich an das DNS wagst. Dazu gehören die Installation von Abhängigkeiten, die Konfiguration des Caching, das Einrichten von Weiterleitungen und die Überprüfung der Leistung.
Teste die Website über eine temporäre URL oder eine lokale Hosts-Datei, damit du sie so sehen kannst, als würde das DNS bereits auf den neuen Server verweisen. Stelle sicher, dass SSL-Zertifikate bereit und gültig sind, insbesondere wenn HTTPS erzwungen wird. Das DNS sollte niemals der Schritt sein, bei dem du Konfigurationsprobleme entdeckst.
Du kannst die DNS-Informationen in MyKinsta ganz einfach anpassen, indem du in deinem Dashboard auf DNS klickst und dann deinen ersten Domainnamen hinzufügst.
2. TTL im Voraus senken
Reduziere die TTL-Werte der relevanten DNS-Einträge rechtzeitig vor der Migration. Idealerweise solltest du dies mindestens 24 Stunden vor dem geplanten Wechsel tun.
Überprüfe nach der Änderung der TTL mit DNS-Lookup-Tools, ob der neue Wert bereits aktiv ist. So stellst du sicher, dass Resolver bereits vor einer IP-Änderung Antworten mit kürzerer Lebensdauer zwischenspeichern.
3. Risikobehaftete Änderungen aussetzen
Pausiere die Inhaltsbearbeitung, E-Commerce-Bestellungen und Formularübermittlungen, sofern die Website auf einer einzigen Datenbank basiert. Da ein DNS-Umzug keine Daten synchronisiert, gehen Änderungen verloren, die nach dem Migrations-Snapshot auf der alten Website vorgenommen werden.
Die meisten Probleme bei der Datenmigration entstehen durch sich überschneidende Schreibvorgänge, nicht durch DNS-Verzögerungen. Das Einfrieren von Änderungen beseitigt dieses Risiko.
4. Aktualisiere DNS-Einträge
Ändere nur die Einträge, die aktualisiert werden müssen, in der Regel A-, AAAA- oder CNAME-Einträge, die auf die Website verweisen. Vermeide es, während desselben Zeitfensters nicht relevante Einträge zu ändern. Du kannst diese Informationen auch in MyKinsta anpassen. Scrolle auf derselben DNS-Seite wie zuvor nach unten zu den DNS-Einträgen und wähle DNS-Eintrag hinzufügen, um diese Informationen manuell einzutragen.
Überprüfe IP-Adressen, Eintragstypen und Hostnamen noch einmal, um Konflikte zu vermeiden. Überprüfe die Änderungen nach der Aktualisierung mit direkten DNS-Abfragen und nicht nur durch Browser-Tests.
Du kannst auch einen automatischen Scan der DNS-Einträge durchführen, indem du unter Automatischer Scan auf Scan starten klickst.
5. Überwache die Ausbreitung in Echtzeit
Verfolge die DNS-Auflösung aus mehreren Regionen, um sicherzustellen, dass der Datenverkehr den neuen Server erreicht. Rechne während der Einführung mit gemischten Ergebnissen. Das ist normal.
Erfolg bedeutet nicht, dass alle sofort aktualisieren. Es bedeutet, dass neuer Datenverkehr konsistent und ohne Fehler oder Unterbrechungen zum richtigen Ziel weitergeleitet wird.
Wenn du diese Reihenfolge befolgst, bleibt das DNS vorhersehbar. Jeder Schritt begrenzt das Risiko, verringert Unsicherheiten und verhindert Ausfallzeiten, die durch überstürzte oder sich überschneidende Änderungen verursacht werden.
Woher Ausfallzeiten normalerweise kommen und wie man sie verhindert
Wenn es während einer Migration zu Ausfallzeiten kommt, wird oft das DNS dafür verantwortlich gemacht. In der Praxis liegt die eigentliche Ursache meist woanders.
DNS-Probleme sind meist einfach und binär: Ein Eintrag verweist auf den richtigen Ort oder eben nicht. Die meisten Ausfälle entstehen durch Lücken zwischen DNS, Hosting und der Anwendung selbst.
- Ein häufiger Fehlerpunkt ist eine falsche IP-Adresse. Ein einziger Tippfehler oder ein veralteter Wert leitet den Datenverkehr an den falschen Server weiter, was wie ein Ausfall aussieht, obwohl das DNS korrekt auflöst.
- Fehlende oder unvollständige DNS-Einträge verursachen ähnliche Symptome. Mail-Einträge, www-Subdomains oder Verifizierungs-Einträge werden bei Änderungen manchmal übersehen, was zu teilweisen Ausfällen oder Funktionsstörungen führt.
- Eine weitere häufige Ursache ist eine SSL-Fehlanpassung. Das DNS verweist zwar auf den neuen Server, aber das Zertifikat ist noch nicht installiert oder deckt die richtige Domain noch nicht ab. Browser blockieren dann den Zugriff, was für Nutzer wie ein Ausfall wirkt.
- Auch Caching kann sich nachteilig auswirken. Zwischengespeicherte Inhalte oder Weiterleitungen verweisen nach DNS-Updates möglicherweise weiterhin auf den alten Server, insbesondere wenn Reverse-Proxys oder CDN-Ebenen nicht auf die neue Umgebung abgestimmt sind.
Der zuverlässigste Weg, diese Probleme zu vermeiden, ist eine Überlappung. Lass die alte und die neue Umgebung gleichzeitig live und voll funktionsfähig, bis sich der Datenverkehr eindeutig verlagert hat. Wenn beide Server Anfragen sicher bedienen können, wird die DNS-Propagierung weitaus weniger riskant.
Wie Managed Hosting DNS-bezogene Risiken reduziert
Managed Hosting kann Migrationsrisiken verringern, indem sichergestellt wird, dass die neue Umgebung vor DNS-Änderungen vollständig vorbereitet ist. Die meisten Managed-Hosting-Plattformen bieten Staging- oder temporäre URLs, vorkonfigurierte Server-Stacks und SSL-Bereitschaftsprüfungen, sodass die neue Website durchgängig getestet werden kann, während die alte Website weiterhin Besucher bedient.
Auch Migrationsunterstützung spielt eine Rolle. Erfahrene Teams überprüfen DNS-Einträge, bestätigen IP-Zuweisungen und achten auf häufige Fehlkonfigurationen, die Ausfälle verursachen. Anstatt zu raten, ob ein Problem auf DNS-, SSL- oder Anwendungsebene liegt, werden Probleme früher im Prozess identifiziert und behoben.
Kinsta strukturiert Migrationen so, dass sich überschneidende Umgebungen die Standardeinstellung sind. Die alte Website bedient weiterhin den Traffic, während die neue Website vorbereitet und überprüft wird. Wenn DNS-Updates erfolgen, sind beide Websites bereit, Anfragen zu bearbeiten.
DNS-Mythen, die unnötige Panik auslösen
Ein Großteil des Migrationsstresses rührt von Vorstellungen über DNS her, die vernünftig klingen, aber nicht zutreffend sind. Wenn man diese aus dem Weg räumt, fällt es leichter, gelassen zu reagieren, wenn die Änderungen nicht sofort wirksam werden.
„DNS-Änderungen erfolgen sofort.“
DNS-Updates werden nicht in Echtzeit ins Internet übertragen. Sie werden erst übernommen, wenn Caches ablaufen und Resolver ihre Daten aktualisieren. Selbst eine perfekt konfigurierte Änderung wird schrittweise ausgerollt.
„Wenn die Website nicht erreichbar ist, ist das DNS defekt.“
Die meisten Ausfallzeiten bei Migrationen werden gar nicht durch das DNS verursacht. SSL-Fehler, Fehlkonfigurationen des Servers oder Probleme mit Anwendungen erscheinen oft als DNS-Fehler, weil Nutzer die Website nicht laden können.
„Das Leeren des Caches behebt die Propagierung.“
Das Leeren des Browser-Caches kann einem einzelnen Nutzer helfen, die neue Website zu sehen, aber es ändert nichts daran, was Resolver oder ISPs zwischengespeichert haben. Die Ausbreitung erfolgt nach deren Zeitplan, nicht nach deinem.
„Bei jeder Migration müssen die Nameserver geändert werden.“
Änderungen an den Nameservern sind nur beim Wechsel des DNS-Anbieters erforderlich. Die meisten Website-Migrationen funktionieren einwandfrei, ohne dass die Nameserver überhaupt berührt werden.
Falls du doch Änderungen vornehmen musst, kannst du in MyKinsta unter DNS > „Nameserver bei deinem Registrar ändern“ auf die Kinsta-Nameserver zugreifen.
DNS verhält sich selten unvorhersehbar, weil es kaputt ist. Es verhält sich vorhersehbar nach Regeln, die leicht missverstanden werden können. Diese Regeln zu kennen, nimmt einen Großteil der Panik, die Migrationen umgibt.
Checkliste nach der Migration: Was zu tun ist, sobald das DNS live ist
Sobald die DNS-Änderungen vorgenommen wurden, ist die Arbeit noch nicht beendet. Das Ziel ist nun, sicherzustellen, dass der Traffic konsistent die neue Umgebung erreicht und dass im Hintergrund nichts unbemerkt fehlschlägt.
- Überprüfe zunächst, ob der Datenverkehr den neuen Server erreicht: Schau dir Serverprotokolle, Analysen oder Hosting-Dashboards an, um sicherzustellen, dass Anfragen bei der richtigen IP-Adresse und Umgebung ankommen. Zu Beginn ist gemischter Datenverkehr normal, aber der Trend sollte vollständig in Richtung der neuen Website gehen.
- Überprüfe SSL und Weiterleitungen: Stelle sicher, dass die Zertifikate für alle erwarteten Domains gültig sind und dass HTTP-zu-HTTPS- sowie Legacy-Weiterleitungen wie vorgesehen funktionieren. Zertifikatsfehler oder Weiterleitungsschleifen treten oft erst auf, wenn echter Datenverkehr eintrifft.
- Überwache Logs und Fehlerraten: Achte auf Spitzen bei 404-Fehlern, 500-Fehlern oder blockierten Anfragen. Diese Signale deuten oft auf übersehene Konfigurationsprobleme hin, die während der Tests nicht sichtbar waren.
- Sobald sich der Datenverkehr stabilisiert hat, stelle die normalen TTL-Werte wieder her: Längere TTLs reduzieren das DNS-Abfragevolumen und verbessern die Effizienz des Resolvers. Dieser Schritt wird oft vergessen, ist aber wichtig für die langfristige Stabilität.
- Entferne alte Umgebungen sicher: Schalte den alten Server erst ab, wenn du sicher bist, dass er keinen nennenswerten Datenverkehr mehr erhält. Ein kurzes Überlappungsfenster verhindert, dass Ausfälle in Randfällen zu Ausfällen führen.
Dieser letzte Schritt macht aus einer erfolgreichen DNS-Aktualisierung eine saubere, stabile Migration.
Ausfallzeiten während der Migration sind in der Regel vermeidbar
Ausfallzeiten während einer Website-Migration sind meist das Ergebnis überstürzter Änderungen, sich überschneidender Zuständigkeiten oder der Behandlung von DNS als etwas, das unter Druck „repariert“ werden muss.
Die sichersten Migrationen legen mehr Wert auf Vorbereitung als auf Geschwindigkeit. Hosting, Anwendungskonfiguration und SSL werden zuerst überprüft. Das DNS wird zuletzt aktualisiert, mit realistischen Erwartungen hinsichtlich der Propagierung und des Caching.
Mit dem richtigen Workflow und der richtigen Unterstützung müssen Website-Migrationen weder stressig noch riskant sein. Und wenn DNS-Änderungen in einer stabilen, verwalteten Umgebung erfolgen, wie beispielsweise den Managed-Hosting-Diensten von Kinsta, gehören Ausfallzeiten der Vergangenheit an.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
