DNS-Propagation ist die Zeit zwischen der Änderung eines DNS-Eintrags und dem Moment, in dem alle den neuen Wert sehen. Dabei wird eigentlich nichts verteilt: Resolver im ganzen Internet liefern weiter die Kopie aus, die sie zwischengespeichert haben, bis deren TTL (Time to Live) abläuft, und fragen dann neu an. Die meisten Änderungen an Einträgen sind innerhalb der TTL des alten Eintrags überall sichtbar, oft nach wenigen Minuten bis zu einer Stunde. Nameserver-Änderungen beim Registrar können bis zu zwei Tage dauern. Um den Stand einer Änderung zu prüfen, fragen Sie zuerst die Nameserver der Domain, was sie veröffentlichen, und dann einige öffentliche Resolver, was sie noch im Cache haben.
Was passiert, wenn Sie einen Eintrag ändern
Der Browser eines Besuchers fragt nicht direkt bei Ihrem DNS-Anbieter nach. Die Anfrage durchläuft mehrere Caches, und jeder davon kann aus dem Gedächtnis antworten:
Der Browser merkt sich aktuelle Antworten für kurze Zeit.
Das Betriebssystem hat einen eigenen Resolver-Cache.
Ein rekursiver Resolver beim Internetanbieter, im Firmennetz oder bei einem öffentlichen Dienst wie 1.1.1.1 oder 8.8.8.8 speichert jede Antwort so lange, wie ihre TTL es erlaubt.
Die autoritativen Nameserver Ihrer Domain halten die echten Einträge. Anfangs wissen nur sie von Ihrer Änderung.
Wenn Sie eine Änderung bei Ihrem DNS-Anbieter speichern, liefern die autoritativen Nameserver sie meist innerhalb von Sekunden oder Minuten aus. Jeder Cache weiter unten behält die alte Antwort, bis seine Kopie abläuft. Zwei Besucher in verschiedenen Netzen können deshalb eine Weile unterschiedliche Server sehen – das ist normal und kein Fehler. Die TTL legen Sie pro Eintrag selbst fest, in Sekunden; der Glossareintrag zur DNS-Propagation fasst das kurz zusammen.
Wie lange DNS-Propagation dauert
Normale Einträge: die alte TTL
Bei einem A-, AAAA-, CNAME-, MX- oder TXT-Eintrag entspricht die längste Wartezeit der TTL, die der alte Eintrag hatte, als die Resolver ihn zwischengespeichert haben. Ein Eintrag mit einer TTL von 3600 kann nach Ihrer Änderung noch bis zu einer Stunde aus dem Cache ausgeliefert werden. Die TTL im selben Moment wie die Änderung zu senken, hilft nicht, denn Resolver, die schon die alte Kopie haben, behalten sie für die alte TTL.
Nameserver-Änderungen: die übergeordnete Zone
Wer eine Domain zu einem anderen DNS-Anbieter umzieht, ändert ihre NS-Einträge beim Registrar. Diese werden in der übergeordneten Zone veröffentlicht, etwa .com, und deren TTL legt die übergeordnete Zone fest, nicht Sie. Das sehen Sie selbst, wenn Sie direkt einen .com-Server fragen:
dig +norecurse @a.gtld-servers.net example.com NS
Die Antwort listet die Nameserver mit einer TTL von 172800 Sekunden, also 48 Stunden. Daher kommt der bekannte Hinweis „bis zu 48 Stunden“. In dieser Zeit fragen manche Resolver beim alten Anbieter und manche beim neuen, deshalb müssen beide dieselben Einträge ausliefern, bis sich die Änderung durchgesetzt hat.
Neue Namen: Negative Caching
Hat jemand einen Namen abgefragt, bevor es ihn gab – zum Beispiel eine neue Subdomain, die Sie zu früh getestet haben –, können Resolver auch die Antwort „diesen Namen gibt es nicht“ zwischenspeichern. RFC 2308 legt fest, wie lange: den kleineren Wert aus dem Minimum-Feld des SOA-Eintrags und der TTL des SOA-Eintrags selbst. Deshalb kann eine brandneue Subdomain in einem Netz eine Zeit lang DNS_PROBE_FINISHED_NXDOMAIN anzeigen und in einem anderen schon funktionieren.
Anwendungen, die an Adressen festhalten
Ein dauerhaft laufendes Programm, etwa ein Anwendungsserver oder ein Proxy, löst einen Hostnamen unter Umständen nur einmal beim Start auf und behält die Adresse bis zum Neustart, ganz gleich, was die TTL sagt. Spricht ein Dienst noch mit dem alten Server, nachdem alle anderen umgezogen sind, starten Sie ihn neu, bevor Sie DNS verdächtigen.
So prüfen Sie die DNS-Propagation
Arbeiten Sie sich von der Quelle nach außen vor. Bestätigen Sie zuerst, dass die Änderung veröffentlicht ist, und sehen Sie dann nach, welche Caches noch die alte Antwort haben.
1. Die autoritativen Nameserver finden
dig NS example.com +short
Sind das nicht die Nameserver des Anbieters, bei dem Sie die Änderung vorgenommen haben, haben Sie die falsche Zone bearbeitet. Das ist ein häufiger Grund dafür, dass sich eine Änderung „nie verbreitet“.
2. Jeden Nameserver direkt fragen
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Wiederholen Sie das für jeden Nameserver in der Liste. Alle sollten den neuen Wert und dieselbe SOA-Seriennummer liefern, das dritte Feld der SOA-Antwort. Ein Server mit einer älteren Seriennummer hat das Update noch nicht erhalten; das ist Propagation innerhalb Ihres Anbieters und erledigt sich meist binnen Minuten.
3. Öffentliche Resolver fragen
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Ohne +short zeigt dig in jeder Antwort die TTL an. Bei einem Resolver ist diese Zahl die Restlaufzeit seiner zwischengespeicherten Kopie: Ein alter Wert mit noch 1200 Sekunden Restzeit wird innerhalb von 20 Minuten ersetzt. Unter Windows fragt nslookup -type=A example.com 1.1.1.1 einen bestimmten Resolver ab, allerdings ohne TTL. Unser kostenloser DNS-Lookup zeigt die Antworten und TTLs für jeden Eintragstyp vom Resolver unseres Servers in Stockholm, ohne dass Sie etwas installieren müssen.
4. Nach einem Nameserver-Umzug der Delegation folgen
dig +trace example.com
+trace beginnt bei der Root-Zone und folgt den Verweisen bis zu Ihren Nameservern, ohne unterwegs Caches zu nutzen. Endet der Trace beim neuen Anbieter, ist die Änderung beim Registrar aktiv, und es bleibt nur noch, dass die Caches nachziehen.
Änderungen so planen, dass die Propagation nicht schadet
Nach einer Änderung lässt sich die Propagation nicht mehr beschleunigen, aber Sie können sie vorher kurz halten. Für einen Umzug auf einen neuen Server:
WannSchrittMindestens eine alte TTL vorherSenken Sie die TTL des Eintrags, zum Beispiel von 3600 auf 300 Sekunden.Vor der ÄnderungRichten Sie den neuen Server ein und testen Sie ihn, etwa mit einem Eintrag in der hosts-Datei oder curl –resolve.Die ÄnderungLassen Sie den Eintrag auf den neuen Server zeigen und prüfen Sie die autoritative Antwort.Während der PropagationLassen Sie den alten Server mit denselben Inhalten weiterlaufen. Einige Besucher landen noch dort.Etwa einen Tag späterErhöhen Sie die TTL wieder und schalten Sie den alten Server ab.
Bei einem Nameserver-Umzug kopieren Sie zuerst alle Einträge zum neuen Anbieter und vergleichen beide Zonen Eintrag für Eintrag, MX und TXT eingeschlossen. Ein vergessener TXT-Eintrag bricht die E-Mail-Authentifizierung; der SPF-, DKIM- und DMARC-Checker zeigt, ob sie noch besteht. Nutzt die Domain DNSSEC, folgen Sie für den DS-Eintrag beim Registrar den Schritten des neuen Anbieters, denn ein DS-Eintrag, der nicht zu den neuen Nameservern passt, lässt validierende Resolver mit SERVFAIL antworten.
Caches leeren, die Sie selbst kontrollieren
Ihre eigenen Caches können Sie leeren, um den neuen Wert früher zu sehen. Das hilft beim Testen, ändert für Ihre Besucher aber nichts.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: Öffnen Sie chrome://net-internals/#dns und leeren Sie den Host-Cache.
Öffentliche Resolver: Bei Cloudflare und Google können Sie einzelne Namen aus dem Cache entfernen lassen, über die Purge-Seite von 1.1.1.1 und die Flush-Seite von Google Public DNS.
Den Resolver Ihres Internetanbieters und die Resolver Ihrer Besucher können Sie nicht von außen leeren. Deren Einträge laufen nach eigenem Zeitplan ab.
Wenn es nicht an der Propagation liegt
Liefern die autoritativen Nameserver noch den alten Wert, hilft Warten nicht. Suchen Sie stattdessen nach einer dieser Ursachen:
Falsche Zone oder falscher Anbieter. Der Eintrag wurde bei einem Anbieter geändert, den die Domain nicht mehr nutzt.
Falscher Name. Die Apex-Domain (example.com) und www.example.com sind getrennte Einträge.
Ein vorgeschalteter Proxy. Ist für den Eintrag ein CDN oder Proxy aktiv, liefert öffentliches DNS bewusst die Adressen des Proxys, nicht die Ihres Servers.
Ein nie gespeicherter Eintrag oder ein Tippfehler im Wert. Vergleichen Sie die Anzeige im Panel des Anbieters mit der Antwort von dig.
Der Glossareintrag zu DNS-Eintragstypen erklärt, wofür jeder Eintrag da ist, und die Checkliste bei Website-Ausfällen beschreibt die Schritte nach DNS.
Mit Uptimecheck erfahren, wenn sich ein Eintrag ändert
Propagation ist die geplante Art von DNS-Änderung. Die ungeplante – ein Tippfehler bei einer Migration oder ein gekapertes Registrar-Konto – ist die, für die sich ein Alarm lohnt. Das DNS-Monitoring von Uptimecheck überwacht A-, AAAA-, CNAME-, MX-, NS-, SOA-, TXT- und CAA-Einträge:
Es fragt direkt die autoritativen Nameserver der Domain ab, sodass eine Änderung beim nächsten Check sichtbar wird, ohne Resolver-Cache dazwischen. Geben die Nameserver unterschiedliche Antworten, zeigt die Monitor-Seite das an.
Ein neuer Satz Einträge wird gemeldet, sobald zwei Checks in Folge ihn gesehen haben, mit altem und neuem Wert, und in der Historie des Eintrags gespeichert.
Tragen Sie die erwarteten Werte ein, dann schlägt der Check fehl, sobald die veröffentlichten Einträge nicht dazu passen. So sehen Sie auch, dass eine geplante Änderung live gegangen ist.
Checks laufen bis zu jede Minute. Start enthält 10 DNS-Monitore, Professional 25 und Business 150.
Kombinieren Sie es mit Uptime-Checks für die Website selbst und dem Monitoring des Domain-Ablaufs. Wie Sie es einrichten, lesen Sie unter DNS-Monitoring einrichten; die Warnzeichen beschreibt So erkennen Sie gekaperte DNS-Einträge.
Erfahren Sie sofort, wenn sich Ihre Einträge ändern. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.