Wie lange die DNS-Propagation dauert, bestimmt die TTL des alten Eintrags: Hatte der A-Record 3600 Sekunden, sehen spätestens nach einer Stunde alle sich korrekt verhaltenden Resolver den neuen Wert. Ein neu angelegter Name ist oft sofort sichtbar. Nameserver-Wechsel dauern länger, bei .de bis zu 24 Stunden, bei .com bis zu 48 Stunden.
„Bis zu 48 Stunden“ steht in fast jeder Support-Antwort zu DNS-Änderungen. Die Zahl ist nicht falsch, sie ist nur für die meisten Fälle viel zu hoch. Wer weiß, woher sie kommt, kann für seine eigene Änderung auf die Minute ausrechnen, wann sie überall sichtbar ist.
Was „Propagation“ eigentlich bedeutet
Der Begriff ist irreführend. Nichts wird verteilt. Deine Änderung liegt in dem Moment, in dem du sie speicherst (plus ein paar Sekunden für die Synchronisation zwischen den Nameservern des Anbieters), auf allen autoritativen Servern der Zone.
Was dauert, ist das Vergessen. Jeder Resolver, der deinen Namen vorher abgefragt hat, darf die Antwort so lange behalten, wie die TTL erlaubt. Erst danach fragt er neu. „DNS-Propagation“ heißt also eigentlich: Ablauf der Caches.
Wie lange dauert die DNS-Propagation wirklich?
Es gibt drei Fälle mit sehr unterschiedlichen Zeiten.
| Änderung | Bestimmende TTL | Typische Dauer |
|---|---|---|
| Neuer Name, nie abgefragt | Keine | Sofort |
| Neuer Name, vorher abgefragt (NXDOMAIN gecacht) | Negativ-TTL aus dem SOA | .de: bis 2 Std., .com: bis 15 Min. |
| Bestehenden A/AAAA/MX ändern | TTL des alten Eintrags | Meist 5 Min. bis 1 Std. |
| Nameserver wechseln | TTL der NS-Delegation in der TLD | .de: bis 24 Std., .com: bis 48 Std. |
Die Werte für .de und .com kommen direkt aus den TLD-Servern und lassen sich nachprüfen:
dig @a.nic.de denic.de NS +norecurse +noall +authoritydenic.de. 86400 IN NS ns1.denic.de.
denic.de. 86400 IN NS ns2.denic.de.86400 Sekunden sind 24 Stunden. Bei .com liefern die Verisign-Server 172800, also 48 Stunden. Das ist die Herkunft der berühmten Zahl.
Die Negativ-TTL: der unterschätzte Fall
Ein Klassiker: Du legst app.example.de an, rufst es sofort im Browser auf, bekommst einen Fehler, weil du dich vertippt hast, korrigierst den Eintrag, und der Name bleibt trotzdem unauflösbar. Dein Resolver hat sich die negative Antwort gemerkt.
Wie lange, steht im SOA-Record der Zone. Nach RFC 2308 gilt das Minimum aus der TTL des SOA-Eintrags und seinem letzten Feld:
dig example.de SOA +noall +answerexample.de. 3600 IN SOA ns1.example-dns.net. hostmaster.example.de. 2026101801 7200 3600 1209600 3600Hier wären es 3600 Sekunden. Lässt du einen Namen erst anlegen und testest dann, umgehst du das Problem komplett.
Propagation prüfen, ohne Webseiten mit Weltkarten
Online-Checker zeigen hübsche Karten, sagen aber wenig darüber, warum ein Resolver noch den alten Wert hat. dig sagt es dir:
Erst fragst du den autoritativen Server, dann die großen öffentlichen Resolver:
dig @ns1.example-dns.net example.de A +noall +answer
dig @1.1.1.1 example.de A +noall +answer
dig @8.8.8.8 example.de A +noall +answer
dig @9.9.9.9 example.de A +noall +answerexample.de. 2412 IN A 198.51.100.7Die 2412 ist die Restlaufzeit im Cache dieses Resolvers. In gut 40 Minuten fragt er neu. Liefert der autoritative Server schon den neuen Wert, bist du fertig und musst nur warten.
Bei Nameserver-Wechseln hilft dig +trace, weil es die Kette von der Root-Zone an selbst abläuft und keinen Cache benutzt:
dig +trace example.de NSWenn es nach Ablauf der TTL immer noch alt ist
Dann liegt es an einer dieser Ursachen, ungefähr in der Reihenfolge ihrer Häufigkeit:
- Lokaler Cache.
resolvectl flush-cachesunter Linux mit systemd-resolved, unter macOSsudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, unter Windowsipconfig /flushdns. Browser cachen zusätzlich, Chrome unterchrome://net-internals/#dns. - Falsche Zone bearbeitet. Die Nameserver der Domain zeigen woanders hin.
dig NS example.de +shortund vergleichen. - Resolver, die die TTL ignorieren. Manche Provider-Resolver halten Einträge länger. Dagegen kannst du nichts tun außer den alten Server eine Weile weiterlaufen zu lassen.
- Mindest-TTL beim Resolver. Einige Resolver setzen eine Untergrenze, sodass 60 Sekunden faktisch zu mehreren Minuten werden.
Google Public DNS und Cloudflare 1.1.1.1 bieten Webformulare an, mit denen du den Cache für einen einzelnen Namen leeren kannst. Das hilft für Tests, nicht für deine Besucher.
Sonderfall: Nameserver-Wechsel mit DNSSEC
Ist deine Domain mit DNSSEC signiert, steht in der Zone der Endung ein DS-Record, der auf den Schlüssel deiner bisherigen Nameserver verweist. Wechselst du die Nameserver, ohne den DS-Record anzupassen oder vorher zu entfernen, passen Signatur und DS nicht mehr zusammen. Validierende Resolver liefern dann SERVFAIL, und die Domain ist für einen großen Teil der Nutzer komplett weg, nicht nur verzögert.
Ob ein DS-Record existiert:
dig example.de DS +shortKommt eine Zeile zurück, gilt: erst DNSSEC beim alten Anbieter sauber abschalten und warten, bis der DS-Record aus der TLD-Zone verschwunden und seine TTL abgelaufen ist, dann die Nameserver wechseln und DNSSEC beim neuen Anbieter wieder einschalten. Bei Records innerhalb derselben Zone betrifft dich das nicht, da signiert der Anbieter die geänderten Einträge selbst neu.
Was während der Übergangszeit passiert
Solange alte Caches leben, bekommen beide Server Traffic. Bei einer statischen Seite ist das egal. Bei einer Anwendung mit Datenbank schreiben Nutzer in der Übergangszeit auf den alten Server, und diese Daten fehlen auf dem neuen. Die übliche Lösung ist, den alten Server nach der Umstellung als Proxy auf den neuen zu konfigurieren, damit alle Schreibzugriffe an einer Stelle landen.
Die Propagation vorher planen
Der eigentliche Trick ist, die Dauer vor der Änderung kurz zu machen. Ein A-Record mit TTL 86400 lässt sich nicht schnell umstellen. Senkst du die TTL einen Tag vorher auf 300, dauert die eigentliche Änderung danach höchstens fünf Minuten. Wie du die TTL dafür wählst, beschreibt der Artikel zur DNS-TTL, den kompletten Ablauf mit beiden Servern parallel Server-Umzug ohne Downtime.
Für Zertifikate gilt: Let’s Encrypt löst über eigene Resolver auf, nicht über den Cache deines Providers oder deines Rechners. Was dein Laptop sieht, ist für die Validierung also kein Maßstab. Entscheidend ist, was der autoritative Server ausliefert und ob die alte TTL abgelaufen ist. Sobald dein A-Record gesetzt ist und der Wechsel durch ist, holst du das Zertifikat.
Nächster Schritt
Bei betadomain pflegst du A-, AAAA- und MX-Einträge im Kundenbereich, und die TTL legst du dort pro Eintrag fest. Suchst du noch eine Adresse, findest du sie über die Domainsuche bei betadomain. Eine .de-Domain registrieren kostet 2,99 € im Jahr, eine .eu-Adresse 10,99 €, jeweils auch bei der Verlängerung.
Domain gefunden? Prüfen und registrieren kannst du sie direkt bei Domains mit festem Jahrespreis – Jahrespreis ab 2,99 €.
Häufige Fragen
Warum sehe ich die neue IP, mein Kollege aber noch die alte?
Ihr nutzt unterschiedliche Resolver mit unterschiedlichen Cache-Ständen. Der Resolver deines Kollegen hat den alten Wert später abgefragt und behält ihn bis zum Ablauf seiner TTL. Mit dig @Resolver-IP kannst du gezielt nachsehen, was ein bestimmter Resolver gerade ausliefert.
Kann ich die DNS-Propagation beschleunigen?
Nur vorher, indem du die TTL einige Zeit vor der Änderung senkst. Ist der alte Wert mit hoher TTL bereits gecacht, kannst du lokal den Cache leeren und bei Google Public DNS und Cloudflare 1.1.1.1 über deren Purge-Seiten einzelne Namen löschen lassen. Alle anderen Resolver musst du abwarten.
Warum sagen Anbieter immer 24 bis 48 Stunden?
Weil das die obere Grenze für Nameserver-Wechsel bei gängigen Endungen ist und Support-Anfragen spart. Für eine normale Änderung eines A-Records mit kurzer TTL ist die Angabe viel zu pessimistisch.
Wie leere ich den DNS-Cache unter Linux?
Mit systemd-resolved reicht resolvectl flush-caches. Nutzt dein System einen lokalen Unbound oder dnsmasq, musst du den jeweiligen Dienst neu laden. Browser haben teilweise einen eigenen Cache, ein Neustart des Browsers hilft dort.