Als DNS-Propagierung (Verbreitung) bezeichnet man den Zeitraum, bis eine DNS-Änderung – beispielsweise die neue IP-Adresse eines A-Eintrags oder ein Wechsel des Nameservers einer Domain – überall wirksam wird. Während dieser Zeit erreichen einige Besucher bereits den neuen, andere hingegen noch den alten Server, und es kann vorkommen, dass auf Ihrem eigenen Computer noch die alte Website geladen wird. Dies ist kein Fehler: Die Änderung wird gemäß den festgelegten Zeitvorgaben automatisch für alle Nutzer wirksam.

Der Ausdruck ist etwas irreführend, da sich die Änderung tatsächlich nirgendwohin „ausbreitet“. Die DNS-Server leiten die neuen Daten nicht untereinander weiter, sondern speichern die zuvor abgefragte Antwort für eine gewisse Zeit in ihrem Cache und fragen erst nach deren Ablauf erneut ab.

Wie werden DNS-Änderungen an die Besucher weitergeleitet?

Wenn jemand „pelda.hu“ in seinen Browser eingibt, fragt sein Computer nicht direkt den Nameserver der Domain ab, sondern einen rekursiven DNS-Server (Resolver). Dabei handelt es sich in der Regel um den des Internetdienstanbieters oder um einen öffentlichen Dienst, beispielsweise die Adressen 1.1.1.1 von Cloudflare oder 8.8.8.8 von Google. Wenn der Resolver die Antwort noch nicht kennt, durchläuft er die gesamte Kette: Von den Root-Servern erfährt er, wer für die Domainendung .hu zuständig ist, von den Servern der Registry für die Domainendung .hu, welche die Nameserver von pelda.hu sind, und schließlich erhält er von diesen autoritativen Nameservern die IP-Adresse der Domain.

Jede Antwort enthält einen TTL-Wert (Time To Live) in Sekunden, der angibt, wie lange der Resolver die Antwort ohne erneute Abfrage verwenden darf. Wenn der A-Eintrag von „pelda.hu“ mit einer TTL von 3600 Sekunden auf die Adresse „192.0.2.10“ verweist und dieser auf die Adresse „203.0.113.20“ geändert wird, gibt der Resolver, der die Domain vor der Änderung abgefragt hat, noch bis zu einer Stunde lang die alte Adresse zurück. Da jeder Resolver zu einem anderen Zeitpunkt eine Abfrage gestellt hat, wechseln die Besucher schrittweise, im Laufe der Stunde nacheinander, auf den neuen Server um.

Neben dem Resolver speichern auch das Betriebssystem Ihres Computers und der Browser DNS-Antworten; daher sehen Sie auf Ihrem Heimcomputer möglicherweise noch die alte Seite, während an anderer Stelle bereits die neue geladen wird.

Wie lange dauert das?

Die Wartezeit hängt davon ab, welche Änderungen Sie vornehmen.

Änderung von Einträgen innerhalb einer Zone (A, AAAA, CNAME, MX, TXT): höchstens bis zum Ablauf der TTL des alten Eintrags, der zum Zeitpunkt der Änderung in den Caches vorhanden war. Die üblichen Werte sind:

TTL	Längste Wartezeit
300	5 Minuten
3600	1 Stunde
14400	4 Stunden
86400	1 Tag

Der neue TTL-Wert hat keine Auswirkungen auf bereits zwischengespeicherte Antworten: Wenn der alte Eintrag einen Tag lang gültig war, bleibt die alte Adresse auf einem Teil der Resolver auch nach der Änderung noch einen Tag lang bestehen, selbst wenn Sie den TTL-Wert auf 5 Minuten setzen.

Wechsel der Nameserver: In diesem Fall sind mehrere Schritte nacheinander erforderlich. Der Registrar leitet die Änderung an die Registry weiter, die die neuen Nameserver in der Domainendung veröffentlicht; anschließend müssen die Resolver die alten Nameserver-Daten vergessen. Die TTL hierfür wird nicht von Ihnen, sondern von der Registry festgelegt:

Domainendung	Die TTL der Nameserver-Daten
.hu	1 Stunde
.eu, .de	1 Tag
.com, .net	2 Tage

Solange ein Resolver die alten Nameserver kennt, fragt er diese ab und erhält somit die alten Zonen-Einträge. Ein Wechsel der Nameserver einer .hu-Domain ist daher in der Regel innerhalb weniger Stunden überall sichtbar, bei einer .com-Domain kann dies jedoch bis zu 48 Stunden dauern. Die seltenen Fälle mit einer Dauer von 72 Stunden werden in der Regel durch Resolver verursacht, die die Antworten länger als die TTL-Zeit speichern.

Ein neuer Eintrag: Eine neue Subdomain oder ein neuer Eintrag ist in der Regel sofort verfügbar. Hat jedoch jemand (auch Sie selbst) bereits vor der Einrichtung danach gesucht, speichert der Resolver die Antwort „Kein solcher Eintrag“ für die im SOA-Eintrag der Zone angegebene Dauer (diese liegt in der Regel zwischen einigen Minuten und einigen Stunden). Daher empfiehlt es sich, eine Subdomain zunächst anzulegen und erst danach zu testen.

Wie können Sie dies verkürzen?

• Verringern Sie die TTL im Voraus. Stellen Sie vor der geplanten Änderung die TTL der zu ändernden Einträge für mindestens die Dauer der aktuellen TTL (bei einer TTL von 86.400 Sekunden also für einen Tag) auf 300 Sekunden ein. Nach der Umstellung erhalten somit alle Nutzer innerhalb weniger Minuten die neue Adresse, woraufhin Sie die TTL wieder auf den ursprünglichen Wert zurücksetzen können. In der Zone Ihres Webhostings können Sie dies bei der Bearbeitung der DNS-Einträge vornehmen. Die TTL der Nameserver-Daten können Sie nicht ändern; wenn also nur die Website umzieht, ist die Änderung des A-Eintrags oft der schnellere Weg (Vergleich der beiden Methoden).
• Lassen Sie den alten Webhosting-Server noch einige Tage lang laufen. Solange die Änderung noch nicht überall durchgeführt wurde, gelangen ein Teil der Besucher und ein Teil der eingehenden E-Mails weiterhin auf den alten Server. Kündigen Sie den alten Dienst nach der Umstellung erst nach mindestens 2–3 Tagen und aktualisieren Sie den Inhalt während des Umzugs nicht auf der alten Seite.
• Testen Sie den neuen Server vor der Umstellung. In der „hosts“-Datei Ihres Computers können Sie die Domain vorübergehend der neuen IP-Adresse zuweisen, sodass Sie die Seite bereits vor der Änderung der DNS-Einstellungen unter der neuen Adresse aufrufen können; die einzelnen Schritte werden im Artikel zur Servermigration beschrieben.

Wie können Sie überprüfen, wo Sie gerade stehen?

Am sichersten ist es, wenn Sie vergleichen, was die autoritativen Nameserver der Domain angeben und was ein öffentlicher Resolver anzeigt. Unser kostenloses DNS-Prüftool fragt direkt die autoritativen Nameserver ab, sodass es nach einer Änderung in der Regel sofort den neuen Wert anzeigt, während die DNS-Eintragsabfrage den Wert liefert, den der Cloudflare-Resolver 1.1.1.1 gerade in seinem Cache gespeichert hat. Wenn die beiden Werte voneinander abweichen, ist die Änderung korrekt vorgenommen worden; Sie müssen lediglich warten, bis die Caches aktualisiert sind.

Über die Befehlszeile (unter Linux und macOS) lässt sich dies mit dem Befehl „dig“ abfragen:

dig NS pelda.hu +short
dig A pelda.hu @ns1.pelda-szolgaltato.hu +short
dig A pelda.hu @1.1.1.1 +noall +answer

Der erste Befehl gibt die Nameserver der Domain an, der zweite fragt direkt einen autoritativen Nameserver ab (geben Sie nach dem @ den vom ersten Befehl zurückgegebenen Nameserver ein), der dritte zeigt die Antwort des öffentlichen Resolvers an. In dieser Antwort gibt die zweite Spalte die verbleibende TTL an, d. h., in wie vielen Sekunden der Resolver den Eintrag erneut abfragt:

pelda.hu.    2843  IN  A  192.0.2.10

Unter Windows liefert der Befehl „nslookup -type=A pelda.hu 1.1.1.1“ ein ähnliches Ergebnis. Weitere Möglichkeiten des Befehls „dig“ werden im Artikel zur Netzwerkfehlerbehebung vorgestellt. Falls die öffentlichen Resolver bereits die neue Adresse anzeigen, Ihr Computer jedoch noch nicht, löschen Sie bitte den lokalen DNS-Cache oder versuchen Sie, die Seite über eine mobile Internetverbindung aufzurufen.

Falls es auch nach einer Wartezeit nicht funktioniert

Wenn auch die autoritativen Nameserver weiterhin den alten Wert ausgeben, wurde die Änderung nicht an der richtigen Stelle vorgenommen: Nach einem Nameserver-Wechsel müssen die Einträge bereits in der Zone des neuen Anbieters bearbeitet werden, nicht mehr in der alten. Sollte die Seite auch nach 48 Stunden noch nicht erreichbar sein, handelt es sich wahrscheinlich nicht um ein Propagationsproblem; die häufigsten Ursachen (falsch eingegebene Nameserver, fehlende Zone, die alte DNSSEC-Einstellung) werden im Artikel „Warum lässt sich meine Website nach einem NS-Wechsel nicht öffnen?“ aufgeführt. Sollten Sie nicht weiterkommen, schreiben Sie uns bitte unter Angabe Ihres Domainnamens, und wir prüfen, wo der Fehler liegt.