Was ist DNS-Propagation und wie begrenzen Sie die Folgen?
Die DNS-Propagation ist der Zeitraum, in dem manche Resolver nach einer Änderung auf dem autoritativen Nameserver weiterhin den alten Wert eines Eintrags ausliefern. Es handelt sich nicht um eine Verbreitung: Jeder Resolver behält seine Antwort im Cache, bis die TTL abgelaufen ist. Die Verzögerung reicht von wenigen Minuten bis zu 24 oder 48 Stunden bei einem Nameserver-Wechsel, je nach TTL des Eintrags vor der Änderung und, bei Nameservern, nach der Delegations-TTL der Registry. So funktioniert es, und so begrenzen Sie die Folgen.
Das Wichtigste in Kürze
- Ihre Änderung ist auf dem autoritativen Server sofort sichtbar. Die Verzögerung entsteht nur durch die Caches der Resolver, die den alten Wert behalten, bis seine TTL abläuft.
- Wie lange der alte Wert bleibt, bestimmt die TTL vor der Änderung, nicht die gerade eingetragene. Senken Sie sie rechtzeitig.
- Ein Nameserver-Wechsel ist am langsamsten, weil er von der Delegations-TTL der Registry abhängt, die Sie nicht kontrollieren.
- Auch Fehler wie „Dieser Name existiert nicht“ werden zwischengespeichert: Wer einen Namen aufruft, bevor sein Eintrag existiert, kann den Fehler verlängern.
Was DNS-Propagation nicht ist: eine Verbreitung
Der Begriff führt in die Irre. Kein Server schickt Ihre Änderung an andere. Wenn Sie eine Änderung bei Ihrem DNS-Anbieter speichern, liefert der autoritative Nameserver der Zone den neuen Wert sofort aus. Die Verzögerung entsteht woanders, in den Caches.
Wenn ein Gerät die Adresse eines Domainnamens sucht, durchläuft die Anfrage mehrere Ebenen, und jede kann die Antwort speichern:
- der Browser, dessen Cache meist etwa eine Minute hält und die TTL nicht immer beachtet;
- das Betriebssystem, das aktuelle Antworten behält;
- der rekursive Resolver Ihres Internetanbieters oder eines öffentlichen Dienstes (zum Beispiel 8.8.8.8 bei Google, 1.1.1.1 bei Cloudflare), der die DNS-Hierarchie durchläuft und das Ergebnis speichert.
Jeder Resolver wendet die TTL an, die ihm der autoritative Server beim Zwischenspeichern der Antwort mitgegeben hat. Da nicht alle zur selben Zeit angefragt haben, laufen ihre Kopien zu unterschiedlichen Zeitpunkten ab. Ein Eintrag mit einer TTL von 3600 Sekunden, der vor 5 Minuten zwischengespeichert wurde, wird in 55 Minuten erneuert. Daher die widersprüchlichen Meldungen: Einer sieht die neue Website, ein anderer die alte, ein dritter einen Fehler.
Wie lange die DNS-Propagation dauert
Die Dauer hängt von der Art der Änderung ab. Eine TTL von einem Tag (86.400 Sekunden) ist üblich, und bei selten geänderten Einträgen wie Nameservern liegen die Werte höher.
| Art der Änderung | Übliche Dauer | Was sie bestimmt |
|---|---|---|
| Änderung eines bestehenden Eintrags (A, AAAA, CNAME, MX, TXT) | Bis zur Dauer der alten TTL, je nach Konfiguration von wenigen Minuten bis 24 Stunden | Die TTL vor der Änderung |
| Anlegen eines Eintrags, den es nicht gab | Variabel, meist höchstens einige Stunden | Das SOA der Zone (SOA-TTL und Feld MINIMUM) |
| Wechsel der Nameserver beim Registrar | Einige Stunden bis 48 Stunden | Die Delegations-TTL der Registry, oft ein bis zwei Tage |
| Resolver mit eigenen Grenzen | Kann die angegebene TTL überschreiten | Eine konfigurierte Ober- oder Untergrenze (standardmäßig 86.400 s bei Unbound, 604.800 s bei BIND) |
Die drei Faktoren, die die Verzögerung bestimmen
Die TTL von vor der Änderung
Angenommen, ein Eintrag hat eine TTL von 86.400 Sekunden und Sie setzen sie heute auf 300. Ein Resolver, der ihn gestern gespeichert hat, behält den alten Wert bis zu 24 Stunden, egal wie der neue Wert lautet: Die TTL von 300 Sekunden gilt erst, wenn seine Kopie erneuert wird. Bei einem CNAME hat jeder Name der Kette eine eigene TTL, und die längste bestimmt die Gesamtverzögerung.
Die Delegation bei der Registry
Beim Wechsel der Nameserver erfolgt die Änderung beim Registrar, der sie an die Registry der Top-Level-Domain weitergibt. Resolver, die noch die alte Nameserver-Liste kennen, fragen diese weiter an, bis die Delegation abläuft. Diese TTL gehört der Registry: Sie können sie nicht verkürzen.
Resolver, die die TTL nicht wörtlich nehmen
Manche Resolver begrenzen oder erhöhen TTLs, und Browser haben einen eigenen kurzlebigen Cache. Überall dieselbe Dauer lässt sich daher nicht garantieren. Die TTL ist eine theoretische Obergrenze, kein Versprechen aller Caches.
Die Falle des Negative Caching
Die meisten Anleitungen behandeln die TTL der Einträge und vergessen die negativen Antworten. Erfährt ein Resolver, dass ein Name nicht existiert (Antwort NXDOMAIN) oder keinen Eintrag des angefragten Typs hat, kann er sich diese Abwesenheit merken. RFC 2308 legt die Dauer des negativen Caches auf den kleineren von zwei Werten fest: die SOA-TTL der Zone und ihr Feld MINIMUM. Sie hält ein bis drei Stunden für sinnvoll und warnt, dass Werte über einem Tag Probleme machen.
Das typische Szenario: Sie testen neu.example.com, bevor der Eintrag existiert, erhalten einen Fehler und legen den Eintrag danach an. Für Ihren Resolver „existiert“ der Name bis zum Ende des negativen Caches nicht, auch wenn der Eintrag seit einer Minute aktiv ist. So vermeiden Sie das:
- Legen Sie den Eintrag an, bevor Sie den Namen testen oder bekanntgeben;
- wenn Ihr DNS-Anbieter das SOA einstellbar macht, wählen Sie ein moderates Feld MINIMUM;
- leeren Sie Ihren lokalen Cache, bevor Sie schließen, dass „es nicht funktioniert“: Laut Microsoft verwirft
ipconfig /flushdnsauch negative Cacheeinträge.
Methode, um die Folgen eines Umzugs zu begrenzen
- Notieren Sie die aktuelle TTL jedes betroffenen Eintrags (siehe die Befehle weiter unten). Sie bestimmt die Verzögerung.
- Senken Sie die TTL auf 300 Sekunden, mindestens so lange im Voraus, wie die alte TTL dauert. Bei 86.400 Sekunden also 24 bis 48 Stunden vor dem Umschalten. Prüfen Sie den Mindestwert Ihres Anbieters.
- Bereiten Sie das neue Ziel vor: Website, Mailserver oder CDN, der denselben Inhalt wie der alte ausliefert. Beide müssen während des Übergangs funktionieren.
- Stellen Sie den Eintrag um, eine Änderung nach der anderen, damit Sie wissen, was zu prüfen ist.
- Prüfen Sie zuerst den autoritativen Server, dann öffentliche Resolver.
- Lassen Sie den alten Server weiterlaufen, mindestens bis die längste alte TTL abgelaufen ist, und schalten Sie ihn erst dann ab.
- Erhöhen Sie die TTL wieder (3600 Sekunden oder mehr), sobald alles stabil läuft.
Bei einem Nameserver-Wechsel legen Sie zuerst die komplette Zone beim neuen Anbieter an (A, CNAME, MX, TXT einschließlich SPF und DKIM und alles Übrige), prüfen, ob sie korrekt antwortet, und ändern erst dann die Nameserver beim Registrar. Lassen Sie die Zone beim alten Anbieter 48 Stunden lang online und identisch: Resolver, die die alte Delegation noch kennen, fragen sie weiter an.
Prüfen, was jeder Resolver sieht
Mit dem Befehl dig (macOS, Linux) oder nslookup (Windows) vergleichen Sie, was der autoritative Server und mehrere öffentliche Resolver antworten.
# Wert und verbleibende TTL bei öffentlichen Resolvern
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1
# Für die Domain eingetragene Nameserver
dig +short NS example.com
# Vom autoritativen Server gelieferter Wert (durch Ihren Nameserver ersetzen)
dig +noall +answer example.com A @ns1.dns-anbieter.example
# SOA-Seriennummer, zum Vergleich zwischen Nameservern
dig +short SOA example.com @ns1.dns-anbieter.example
dig +short SOA example.com @ns2.dns-anbieter.example
# Entsprechung unter Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com
In der Antwort eines Resolvers sinkt die angezeigte TTL von Anfrage zu Anfrage: Sie ist die Zeit, die bis zum Ablauf seiner Kopie bleibt. Liefert ein Resolver den alten Wert mit einer weiter herunterzählenden TTL, während der autoritative Server schon den neuen liefert, müssen Sie nur warten.
Vergleichen Sie außerdem die SOA-Seriennummer Ihrer Nameserver. Weichen sie ab, liefert ein Server veraltete Daten: Das Problem liegt dann bei Ihrem DNS-Anbieter, nicht an der Propagation. Auf dns.google können Sie einen bestimmten Eintragstyp, auch SOA, abfragen, und die Fehlerbehebung von Google Public DNS beschreibt diese Prüfung.
Caches leeren, die Sie selbst kontrollieren
Das Leeren des eigenen Caches ändert für andere Besucher nichts, zeigt Ihnen aber, was Sie tatsächlich sehen.
# Windows (Eingabeaufforderung)
ipconfig /flushdns
# Aktuelles macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux mit systemd-resolved
resolvectl flush-caches
Microsoft beschreibt /flushdns und /displaydns auf der Seite zum Befehl ipconfig. Schließen Sie danach den Browser vollständig, denn er hat ein eigenes Kurzzeitgedächtnis.
Zwei öffentliche Resolver bieten außerdem eine Bereinigung, nützlich nach einem Nameserver-Wechsel oder für Nutzer dieser Dienste: das Werkzeug Flush Cache von Google Public DNS (Google rät, sowohl die registrierte Domain als auch den genauen Namen mit der veralteten Antwort zu bereinigen) und die Cache-Bereinigung von 1.1.1.1 bei Cloudflare, bei der Sie Domain und Eintragstyp wählen. Die Resolver der Internetanbieter lassen sich nicht bereinigen: Hier heißt es warten, bis ihre Kopien ablaufen.
Häufige Fehler
- Die TTL erst beim Umschalten senken. Dann ist es zu spät: Die Resolver behalten die mit der alten TTL angelegte Kopie.
- Den Namen testen, bevor der Eintrag existiert. Negative Caching kann den Fehler verlängern.
- Nameserver wechseln, bevor die ganze Zone neu angelegt ist. Vergessene Mail- oder Subdomain-Einträge funktionieren für Resolver, die bereits den neuen Anbieter fragen, nicht mehr.
- Den alten Server zu früh abschalten. Besucher, deren Cache noch nicht abgelaufen ist, landen auf einem Server, der nicht mehr antwortet.
- Vom eigenen Rechner auf das Ende der Propagation schließen. Ihr lokaler Cache steht nicht für die übrigen Resolver.
- Eine sehr niedrige TTL dauerhaft belassen. Sie vervielfacht die Anfragen an Ihre Nameserver. Erhöhen Sie sie nach dem Umzug wieder.
Häufig gestellte Fragen
Wie lange dauert die DNS-Propagation?
Bei der Änderung eines Eintrags höchstens so lange wie die alte TTL: eine Stunde bei 3600 Sekunden, 24 Stunden bei 86.400. Bei einem Nameserver-Wechsel einige Stunden bis 48 Stunden. Die meisten Resolver aktualisieren sich deutlich vor Ablauf der Maximaldauer. Übrig bleiben einige nachzüglerische Caches.
Lässt sich die DNS-Propagation beschleunigen?
Nicht im gesamten Internet: Fremde Caches lassen sich nicht erzwingen. Sie können die TTL vor der Änderung senken, die öffentlichen Resolver von Google und Cloudflare bereinigen und Ihre eigenen Caches leeren. Die Resolver der Internetanbieter lassen sich nicht bereinigen.
Welche TTL sollte ich vor einem Umzug wählen?
Einen kurzen Wert wie 300 Sekunden (5 Minuten), mindestens so lange vor dem Umschalten gesetzt, wie die alte TTL dauert. Ist der Umzug stabil, erhöhen Sie sie wieder auf 3600 Sekunden oder mehr: Eine dauerhaft sehr niedrige TTL vervielfacht die Anfragen. Prüfen Sie den Mindestwert Ihres DNS-Anbieters.
Warum sieht mein Kollege die neue Website und ich nicht?
Sie nutzen unterschiedliche Resolver, die die Antwort zu verschiedenen Zeitpunkten gespeichert haben. Fragen Sie von beiden Rechnern denselben öffentlichen Resolver ab, um zu vergleichen, und leeren Sie den lokalen Cache des Rechners, der noch die alte Version zeigt.
Was passiert während der Propagation mit meinen E-Mails?
Eine Änderung des MX-Eintrags folgt denselben Regeln: Während der Verzögerung schreiben manche Absender noch an den alten Mailserver. Lassen Sie ihn bis zum Ende des Übergangs aktiv. Ist ein Server nicht erreichbar, behalten die sendenden Server die Nachrichten in der Regel und versuchen es mehrere Tage lang erneut.
Muss ich den Cache meines Computers leeren?
Ja, um zu prüfen, was Sie sehen, doch für andere Besucher ändert sich nichts. Nutzen Sie den Befehl Ihres Systems und schließen Sie den Browser vollständig. Zeigt sich weiterhin der alte Wert, hält der Resolver Ihres Internetanbieters die Kopie.
Warum zeigen Online-Prüfwerkzeuge unterschiedliche Ergebnisse?
Jedes fragt Resolver in anderen Ländern ab, die die Antwort zu verschiedenen Zeitpunkten gespeichert haben. Ein gemischtes Ergebnis ist normal, solange die TTL nicht überall abgelaufen ist. Antworten die autoritativen Nameserver selbst unterschiedlich, vergleichen Sie ihre SOA-Seriennummern: Dann liegt das Problem in der Zone, nicht in der Propagation.