DNS-Änderung: wie lange dauert es, bis sie überall gilt?

Du hast die IP-Adresse deiner Website geändert, auf deinem Rechner erscheint schon der neue Server, ein Kollege sieht noch den alten. Der Grund ist das Zwischenspeichern. Resolver, die DNS-Anfragen für Nutzer beantworten, merken sich jede Antwort für die Zeit, die der Eintrag selbst vorgibt: die TTL ^[1]. Bis sie abläuft, fragen sie nicht nach. Der verbreitete Begriff "DNS-Propagation" klingt nach einer Verteilung, die irgendwo im Netz läuft. Tatsächlich laufen viele Zwischenspeicher unabhängig voneinander ab.

Was bei einer Änderung passiert

Sobald du einen Eintrag bei deinem DNS-Anbieter speicherst und dieser die Zone auf seinen Nameservern aktualisiert hat, antworten diese mit dem neuen Wert. Ein Resolver, der den Namen noch nie oder seit Ablauf der TTL nicht mehr abgefragt hat, bekommt sofort die neue Antwort. Ein Resolver, der ihn vor zehn Minuten abgefragt hat, liefert weiter den alten Wert, bis die TTL abgelaufen ist ^[1].

Weil jeder Resolver den Namen zu einem anderen Zeitpunkt zuletzt abgefragt hat, läuft die Zeit überall unterschiedlich ab. Deshalb sehen manche Nutzer schon den neuen Stand, andere noch den alten. Dazu kommen Zwischenspeicher im Betriebssystem und im Browser. Unter Windows zeigt ipconfig /displaydns den Inhalt des lokalen DNS-Caches, ipconfig /flushdns leert ihn ^[7].

Die TTL bestimmt die Wartezeit

Die TTL steht in jedem Eintrag und wird in Sekunden angegeben. Sie legt fest, wie lange ein Eintrag im Cache bleiben darf; eine TTL von 0 verbietet das Zwischenspeichern ^[1]. Die längste Wartezeit nach einer Änderung entspricht damit ungefähr der TTL, die der alte Eintrag hatte.

Wichtig ist die TTL des alten Eintrags. Senkst du die TTL erst zusammen mit der Änderung, haben Resolver den alten Wert noch mit der alten, langen TTL gespeichert. Wie du die TTL sinnvoll wählst, erklärt der Beitrag TTL bei DNS.

Was große Resolver daraus machen

Öffentliche Resolver begrenzen die Speicherdauer teilweise nach oben. Google Public DNS schreibt, dass Einträge dort in der Regel höchstens sechs Stunden im Cache bleiben, auch wenn die TTL länger ist ^[4]. Cloudflare gab für seinen Resolver 1.1.1.1 an, Einträge höchstens drei Stunden zu speichern und kürzere TTLs einzuhalten ^[5]. Bei den Resolvern von Internetanbietern und in Firmennetzen gibt es solche Angaben meist nicht. Dort gilt die TTL des Eintrags.

Es gibt auch den umgekehrten Fall. Nach RFC 8767 darf ein Resolver eine abgelaufene Antwort weiter ausliefern, wenn er die zuständigen Nameserver nicht erreicht. Die RFC schlägt vor, solche Daten höchstens ein bis drei Tage aufzuheben ^[6]. Das hilft bei Ausfällen. Es bedeutet aber auch, dass ein abgeschalteter alter Nameserver nicht sofort aus allen Antworten verschwindet.

Warum ein Nameserver-Wechsel länger dauert

Am längsten dauert der Wechsel des DNS-Anbieters, also der Nameserver. Die NS-Einträge stehen in der übergeordneten Zone, bei .de also bei der Registry, und tragen dort ihre eigene TTL. Amazon nennt 172.800 Sekunden, also zwei Tage, als typischen Wert für NS-Einträge und weist darauf hin, dass manche Resolver die TTL der NS-Einträge aus der übergeordneten Zone verwenden ^[2]. Ein Resolver, der die alten Nameserver vor wenigen Minuten erfragt hat, nutzt sie bis zu zwei Tage weiter ^[2].

Daraus folgt eine einfache Regel: Beim Anbieterwechsel müssen alte und neue Nameserver für einige Tage dieselben Einträge liefern. Kündigst du den alten DNS-Anbieter sofort, laufen Anfragen von Resolvern mit altem Stand ins Leere. Den Ablauf im Einzelnen beschreibt Nameserver ändern. Ist DNSSEC aktiv, kommt ein weiterer Schritt hinzu: Amazon empfiehlt, den DS-Eintrag in der übergeordneten Zone vor dem Wechsel zu entfernen und DNSSEC danach neu einzurichten ^[2].

Auch ein "gibt es nicht" wird gespeichert

Ein häufig übersehener Fall: Du rufst eine neue Subdomain auf, bevor du den Eintrag angelegt hast. Der Resolver bekommt die Antwort, dass es den Namen nicht gibt, und merkt sich auch diese. Wie lange, ergibt sich aus dem SOA-Eintrag der Zone: Es gilt der kleinere Wert aus dem Feld MINIMUM und der TTL des SOA ^[3]. Resolver dürfen das zusätzlich begrenzen; RFC 2308 nennt ein bis drei Stunden als bewährten Wert ^[3].

E-Mail während der Umstellung

Ändert sich der MX-Eintrag, gilt dasselbe wie bei der Website: Bis die TTL abgelaufen ist, stellen manche Absender noch beim alten Mailserver zu. Läuft der alte Server weiter und nimmt Mails an, landen sie dort im alten Postfach. Sinnvoll ist deshalb, das alte Postfach nach der Umstellung noch einige Tage abzurufen oder eine Weiterleitung einzurichten.

Ist der alte Server dagegen schon abgeschaltet, gehen die Mails in der Regel nicht verloren. Ein sendender Mailserver muss nach einem Fehlschlag warten und es erneut versuchen. RFC 5321 nennt als Abstand mindestens 30 Minuten und als Zeitraum, bevor er aufgibt, in der Regel mindestens vier bis fünf Tage ^[8]. Die Zustellung verzögert sich dann aber, und ob ein Absender die Norm so großzügig auslegt, hängt von seinem Server ab. Wie der neue MX gesetzt wird, steht unter MX-Eintrag einrichten.

Den neuen Server vorher testen

Du musst nicht auf das Ende der Wartezeit warten, um den neuen Server zu prüfen. Auf deinem eigenen Rechner kannst du dem Namen in der Hosts-Datei vorübergehend die neue IP-Adresse zuordnen. Windows lädt die Einträge dieser Datei in seinen DNS-Cache und nutzt sie vor jeder Anfrage an einen DNS-Server ^[7]. So siehst du die Website auf dem neuen Server, während alle anderen noch beim alten landen. Den Eintrag in der Hosts-Datei löschst du nach dem Test wieder, sonst bemerkst du spätere Änderungen nicht.

Ob deine Nameserver den neuen Wert schon ausliefern, prüfst du, indem du sie direkt fragst, etwa mit dig und dem Namen des Nameservers. Sie antworten mit den aktuellen Daten ihrer Zone ^[1].

Eine Änderung planen

Wer weiß, dass eine Änderung ansteht, etwa ein Umzug zu einem anderen Hoster, kann die Wartezeit vorher verkürzen. Amazon beschreibt das Vorgehen für den Wechsel der Nameserver ^[2]. Weil für jeden Eintrag dieselbe TTL-Regel gilt, lässt es sich auf A-, AAAA- und MX-Einträge übertragen ^[1].

1. Die TTL der betroffenen Einträge senken. Für den NS-Eintrag empfiehlt Amazon beim Anbieterwechsel 60 bis 900 Sekunden ^[2]; bei anderen Einträgen gilt dasselbe Prinzip ^[1].
2. So lange warten, wie die alte TTL war. Erst dann haben alle Resolver den Eintrag mit der kurzen TTL ^[2].
3. Die eigentliche Änderung vornehmen und den alten Server oder die alten Nameserver weiterlaufen lassen.
4. Prüfen, ob die Zugriffe auf dem neuen Ziel ankommen. Bei Problemen lässt sich wegen der kurzen TTL schnell zurückstellen ^[2].
5. Die TTL wieder erhöhen, damit Resolver seltener nachfragen müssen ^[2].

Wie ein Serverumzug ohne Ausfall abläuft, steht in Webhosting wechseln ohne Ausfall. Ändert sich bei einem Relaunch auch die Adresse der Seiten, hilft der Beitrag Website-Relaunch ohne Rankingverlust auf seo.domain-root.de.

Prüfen, ob die Änderung angekommen ist

Mit dem DNS-Check siehst du, was der Resolver unseres Servers gerade liefert. Zeigt er noch den alten Wert, hat er den Eintrag im Cache. Einige öffentliche Resolver erlauben es, einzelne Einträge vorzeitig zu erneuern:

• Google Public DNS hat eine Funktion "Flush Cache" für gängige Eintragstypen. Nach einem Wechsel des Registrars oder DNS-Anbieters soll man zuerst die Hauptdomain und danach die Subdomains erneuern ^[4].
• Cloudflare bietet für 1.1.1.1 eine Seite zum Leeren des Caches unter cloudflare-dns.com/purge-cache an ^[5].
• Auf dem eigenen Windows-Rechner leert ipconfig /flushdns den lokalen Cache, einschließlich gespeicherter negativer Antworten ^[7].

Die Resolver deines Internetanbieters oder deiner Firma kannst du so nicht beeinflussen. Dort hilft nur Warten, bis die TTL abgelaufen ist. Bleibt eine Seite auch danach unerreichbar, liegt der Fehler meist woanders; die Schritte dazu stehen unter Website nicht erreichbar.

1. Gesetz RFC 1034: Domain Names, Concepts and Facilities. IETF. Stand November 1987. abgerufen am 29.10.2026
2. Organisation Making Route 53 the DNS service for a domain that's in use. Amazon Web Services. Stand 2026. abgerufen am 29.10.2026
3. Gesetz RFC 2308: Negative Caching of DNS Queries (DNS NCACHE). IETF. Stand März 1998. abgerufen am 29.10.2026
4. Organisation Google Public DNS: Frequently Asked Questions. Google. Stand 2026. abgerufen am 29.10.2026
5. Organisation Refresh Stale DNS Records on 1.1.1.1. Cloudflare Blog. Stand 21.08.2018. abgerufen am 29.10.2026
6. Gesetz RFC 8767: Serving Stale Data to Improve DNS Resiliency. IETF. Stand März 2020. abgerufen am 29.10.2026
7. Organisation ipconfig. Microsoft. Stand 2026. abgerufen am 29.10.2026
8. Gesetz RFC 5321: Simple Mail Transfer Protocol. IETF. Stand Oktober 2008. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.