Wie sich DNS weltweit verbreitet

Sie ändern einen A-Record, laden den Browser neu und sehen trotzdem den alten Server. Eine Kollegin in einer anderen Stadt sieht schon den neuen. Jemand rät Ihnen, „auf die DNS-Propagation zu warten“ – das könne bis zu 48 Stunden dauern. Diese Floskel ist so verbreitet, dass sich die meisten vorstellen, DNS-Änderungen würden sich wie eine Welle langsam über den Planeten ausbreiten. Die Wirklichkeit ist einfacher – und lässt sich, sobald man sie verstanden hat, viel besser steuern.

Dieser Leitfaden erklärt, was bei einer DNS-Änderung tatsächlich passiert, warum verschiedene Menschen im selben Moment unterschiedliche Antworten sehen, wie sich Nameserver-Wechsel von gewöhnlichen Record-Änderungen unterscheiden und wie Sie den Vorgang prüfen und beschleunigen. Wenn Sie zuerst die Record-Typen auffrischen möchten, lesen Sie unseren Leitfaden zu den Grundlagen von DNS-Records.

Propagation ist in Wahrheit Cache-Ablauf

Nichts wird im Sinne einer Kopie von Server zu Server rund um den Globus „propagiert“. Bearbeiten Sie einen Record bei Ihrem DNS-Anbieter, landet die Änderung fast sofort auf Ihren autoritativen Nameservern (die meisten Anbieter synchronisieren ihre eigenen Server innerhalb von Sekunden bis wenigen Minuten). Ab diesem Moment steht die korrekte Antwort jedem zur Verfügung, der danach fragt.

Die Verzögerung entsteht bei den rekursiven Resolvern: den DNS-Servern von Internetanbietern, Unternehmen und öffentlichen Diensten wie Google Public DNS, Cloudflare 1.1.1.1 oder Quad9. Schlägt ein Resolver Ihre Domain nach, speichert er die Antwort so lange in seinem Cache, wie es die TTL (Time to Live) des Records erlaubt. Bis dieser Timer abläuft, gibt er die gespeicherte Antwort weiter, ohne Ihre Nameserver erneut zu fragen.

Wenn also von Propagation die Rede ist, lautet die eigentliche Frage: „Wie lange dauert es, bis jeder Resolver, der die alte Antwort gecacht hat, sie verfallen lässt?“ Jeder Resolver hat Ihren Record zu einem anderen Zeitpunkt gespeichert, also läuft er auch zu einem anderen Zeitpunkt ab. Deshalb wirken die Ergebnisse während einer Umstellung zufällig und lückenhaft. Mehr zur Wahl passender TTL-Werte lesen Sie unter Die Rolle der DNS-TTL-Einstellungen.

Die Cache-Schichten zwischen Ihnen und der Antwort

Ein einzelner Lookup kann mehrere Caches durchlaufen, und jeder davon kann den alten Wert vorhalten:

• Browser-Cache – Browser führen einen eigenen, kurzlebigen DNS-Cache.
• Cache des Betriebssystems – Windows, macOS und viele Linux-Setups (etwa mit systemd-resolved) speichern Antworten lokal.
• Router oder lokales Netz – Heimrouter und DNS-Forwarder im Büro cachen häufig ebenfalls.
• Rekursiver Resolver – der Ihres Internetanbieters oder ein öffentlicher, den sich viele Nutzer teilen.
• Negativer Cache – hat jemand einen Namen abgefragt, bevor er existierte, wird die Antwort „existiert nicht“ gemäß den SOA-Einstellungen der Zone gecacht.

Manche Resolver wenden zudem eigene Mindest- oder Höchst-TTLs an, und einige behalten Records nachweislich länger als vorgegeben. Auch deshalb sollten Sie jeden Zeitrahmen, den Sie lesen, als typischen Bereich verstehen, nicht als Garantie.

Record-Änderungen vs. Nameserver-Wechsel

Nicht alle DNS-Änderungen verhalten sich gleich. Entscheidend ist, wo die gecachten Daten liegen.

Einen Record in Ihrer Zone ändern

Die Bearbeitung eines A-, AAAA-, CNAME-, MX- oder TXT-Records betrifft nur Daten auf Ihren eigenen autoritativen Servern. Die Wartezeit bestimmt die TTL, die der Record vor Ihrer Änderung hatte. Hatte der alte A-Record eine TTL von 3600 Sekunden, können Resolver, die ihn kurz vor Ihrer Bearbeitung gecacht haben, ihn bis zu einer Stunde behalten.

Nameserver wechseln

Der Umzug zu einem neuen DNS-Anbieter bedeutet, die NS-Records bei Ihrem Registrar zu ändern, der das Update an die Registry Ihrer TLD (etwa .com oder .de) weitergibt. Die Registry veröffentlicht dann die neue Delegation in der Elternzone. Hier summieren sich zwei Verzögerungen:

1. Die Zeit, die Registrar und Registry für Verarbeitung und Veröffentlichung brauchen. Viele Registries veröffentlichen innerhalb von Minuten, das variiert aber je nach TLD.
2. Die TTL der Delegations-NS-Records in der Elternzone, auf die Sie keinen Einfluss haben. Bei .com und .net sind das häufig zwei Tage (172800 Sekunden); andere TLDs nutzen eigene Werte.

Resolver können außerdem die NS-Records cachen, die die Server Ihres alten Anbieters ausliefern. Deshalb sind Nameserver-Wechsel der klassische „bis zu 48 Stunden“-Fall, während eine einfache Record-Änderung mit niedriger TTL in Minuten erledigt sein kann. Halten Sie während einer Anbietermigration auf alten und neuen Nameservern identische Records vor, bis der Traffic vollständig umgezogen ist.

Diese Bereiche sind allgemeine Muster, keine Zusagen. Das Verhalten der Resolver, die Verarbeitung bei der Registry und wie kürzlich jeder Resolver Ihren Namen abgefragt hat, beeinflussen das tatsächliche Ergebnis.

Eine Änderung so planen, dass sie schnell geht

Da die alte TTL die Wartezeit bestimmt, besteht der Trick darin, sie zu senken, bevor Sie die Änderung vornehmen:

1. Aktuelle TTL prüfen – bei den Records, die Sie ändern wollen.
2. TTL senken auf einen kurzen Wert wie 300 Sekunden, mindestens eine volle alte TTL-Periode im Voraus (lag die TTL bei 86400, also mehr als einen Tag vorher).
3. Änderung durchführen, sobald die alte, lange TTL überall ablaufen konnte.
4. Prüfen, ob mehrere Resolver die neuen Antworten liefern.
5. TTL wieder anheben, sobald alles stabil läuft, um Abfragelast zu senken und die Ausfallsicherheit zu verbessern.

Bei Nameserver-Umzügen können Sie die TTL der Elternzone nicht verkürzen, Ausfälle aber vermeiden, indem Sie beide Anbieter mit identischen Records parallel betreiben.

Den Fortschritt über mehrere Resolver prüfen

Ein einzelner Test vom eigenen Laptop zeigt nur, was Ihre lokale Cache-Kette glaubt. Für ein realistisches Bild vergleichen Sie mehrere Quellen. Mit dig fragen Sie gezielt einen Resolver ab, indem Sie seine Adresse hinter das @-Zeichen setzen:

dig example.com A +short @1.1.1.1
dig example.com A +short @8.8.8.8
dig example.com A +short @9.9.9.9

Um an allen Caches vorbei zu sehen, was Ihre eigenen Server sagen, fragen Sie einen autoritativen Nameserver direkt:

dig example.com NS +short
dig example.com A @ns1.your-dns-provider.net

Die TTL-Spalte einer normalen dig-Antwort verrät zudem, wie viele Sekunden noch vergehen, bis ein Resolver seine gecachte Kopie erneuert – praktisch, um die verbleibende Wartezeit abzuschätzen. Bei Nameserver-Wechseln verfolgen Sie die Delegation ab der Root mit dig example.com +trace. Welche Nameserver die Registry aktuell führt, bestätigen Sie mit dem Domain-WHOIS/RDAP-Lookup von TLDix.

Online-„Propagation-Checker“, die Resolver in vielen Ländern abfragen, eignen sich für einen schnellen Überblick. Bedenken Sie aber, dass sie nur eine Stichprobe von Resolvern zu einem einzigen Zeitpunkt zeigen.

Lokale Caches leeren

Liefern öffentliche Resolver bereits die neue Antwort, Ihr Rechner aber nicht, liegt die veraltete Kopie vermutlich lokal. Gängige Wege, sie zu löschen:

• Windows: ipconfig /flushdns in einem Terminal ausführen.
• macOS: sudo dscacheutil -flushcache und anschließend sudo killall -HUP mDNSResponder ausführen.
• Linux mit systemd-resolved: resolvectl flush-caches ausführen.
• Chrome: chrome://net-internals/#dns öffnen und den Host-Cache leeren.
• Router: Ein Neustart leert in der Regel seinen Cache.

Den Resolver Ihres Internetanbieters können Sie nicht selbst leeren. Einige öffentliche Resolver, darunter Google und Cloudflare, bieten Webformulare an, um einen gecachten Namen zu verwerfen – beim Testen kann das helfen.

Typische Probleme, die wie langsame Propagation aussehen

Viele „Propagation“-Beschwerden entpuppen sich als Konfigurationsfehler. Bevor Sie länger warten, schließen Sie Folgendes aus:

• Die falsche Zone bearbeitet – Änderungen im DNS-Panel des Registrars bewirken nichts, wenn die Domain andere Nameserver nutzt.
• Tippfehler in Records – ein fehlender Punkt oder eine falsche IP-Adresse sieht genauso aus wie eine alte, gecachte Antwort.
• DNSSEC-Unstimmigkeit – nach einem Anbieterwechsel kann ein veralteter DS-Record bei der Registry validierende Resolver komplett scheitern lassen.
• CDN- oder Proxy-Schichten – läuft der Traffic über ein CDN, kann das DNS korrekt sein, während das CDN noch auf den alten Origin zeigt.
• Caching in Anwendungen – manche Software und lang laufende Prozesse lösen einen Namen einmal auf und behalten das Ergebnis bis zum Neustart.

Praxisbeispiel: Mailumzug ohne verlorene Nachrichten

Besonders heikel sind MX-Änderungen, weil verlorene E-Mails kaum auffallen. Senken Sie die TTL der MX-Records zwei Tage vor dem Umzug auf 300 Sekunden und richten Sie die Postfächer beim neuen Anbieter vollständig ein, bevor Sie umstellen. Lassen Sie die alten Postfächer nach der Änderung noch mindestens einige Tage aktiv und rufen Sie sie weiter ab, denn sendende Server mit veralteten Caches stellen womöglich noch dort zu. Passen Sie gleichzeitig SPF-, DKIM- und DMARC-Einträge an, damit Ihre ausgehenden Nachrichten nicht im Spam landen.

Domain- und DNS-Details im Blick behalten

DNS-Änderungen gehen oft mit anderen Ereignissen einher: einem Hosterwechsel, der Verlängerung einer Domain oder dem Austausch eines SSL-Zertifikats. Wer weiß, welche Nameserver eine Domain nutzt, wer sie hostet und wann sie abläuft, spart Zeit, wenn etwas schiefgeht. Mit TLDix schlagen Sie Registrierungsdaten nach und verfolgen Verlängerungstermine, und der Hosting-Lookup zeigt, von wo eine Website aktuell ausgeliefert wird – praktisch direkt nach einer Migration.

Die wichtigste Lektion ist einfach: DNS-Änderungen erreichen die Welt so schnell, wie alte Caches ablaufen. Planen Sie TTLs vorausschauend, prüfen Sie über mehrere Resolver – dann müssen Sie selten die vollen 48 Stunden warten.