Was ist DNS-Propagation? Warum DNS-Änderungen Zeit benötigen

Sie aktualisieren die DNS-Einträge einer Domain, speichern die Änderung und erwarten, dass die neue Website oder der Maildienst sofort funktioniert. Doch ein Kollege sieht weiterhin die alte Website, ein Online-Prüftool zeigt eine andere Adresse an oder die E-Mail-Zustellung verhält sich inkonsistent. Diese Verzögerung wird allgemein als DNS-Propagation.

Der Ausdruck kann den Eindruck erwecken, als würde ein einzelnes Update durch ein zentrales Internetsystem übertragen. DNS ist jedoch dezentral strukturiert. Domäneninformationen werden auf autoritativen Nameservern, rekursiven Resolvern, Routern, Betriebssystemen und Anwendungen gespeichert und zwischengespeichert. Jedes System kann seine Informationen zu unterschiedlichen Zeitpunkten aktualisieren.

Die meisten DNS-Änderungen werden sichtbar, wenn die Caches ablaufen und Resolver neue Datensätze abrufen. Wie lange dies dauert, hängt von der vorherigen Time to Live (TTL) des Datensatzes, dem Verhalten der Resolver sowie davon ab, ob die Konfiguration der autoritativen DNS korrekt ist. Es gibt keine universelle Zeit, die garantiert, dass jeder Benutzer die neue Antwort sieht.

Dieser Leitfaden erklärt, was mit der DNS-Propagierung gemeint ist, warum DNS-Änderungen zu unterschiedlichen Zeitpunkten wirksam werden, wie Sie die aktuellen Antworten einer Domain überprüfen können und welche Schritte Sie unternehmen sollten, wenn ein Update weiterhin unvollständig erscheint.

Was bedeutet DNS-Propagation?

DNS-Propagation ist der gängige Begriff für den Zeitraum, in dem verschiedene Benutzer oder DNS-Resolver unterschiedliche Antworten erhalten können, nachdem DNS-Einträge geändert wurden. Ein Benutzer in einem Netzwerk sieht möglicherweise bereits die neue IP-Adresse, während der Resolver eines anderen Benutzers weiterhin eine zwischengespeicherte ältere Adresse zurückgibt.

Die zugrunde liegende DNS-Änderung wird auf den autoritativen Nameservern für die Domain vorgenommen. Rekursive Resolver rufen dann die Datensätze ab und cachen sie für ihre Benutzer. Diese Resolver müssen nicht jedes Mal, wenn jemand die Domain aufruft, erneut die autoritativen Server fragen. Sie können eine zwischengespeicherte Antwort wiederverwenden, solange diese gültig bleibt.

Dies ist der Grund, warum „Propagation“ besser verstanden wird als Cache-Ablauf und -Aktualisierung. Es gibt keine zentrale Kopie, die auf jedem internetfähigen Gerät gleichzeitig aktualisiert werden muss. Der autoritative Datensatz kann bereits korrekt sein, während einige Resolver weiterhin ältere zwischengespeicherte Daten bereitstellen.

So funktioniert das DNS-Caching

Wenn ein Browser die IP-Adresse einer Domain ermitteln muss, bittet er das Betriebssystem um die Auflösung des Namens. Das Betriebssystem kann eine zwischengespeicherte Antwort haben. Falls nicht, fragt es einen konfigurierten rekursiven Resolver an, wie zum Beispiel einen eines Internetanbieters, eines Unternehmens oder eines öffentlichen DNS-Dienstes.

Der rekursive Resolver kann auch eine zwischengespeicherte Antwort haben. Wenn diese Antwort noch innerhalb ihrer Cache-Lebensdauer liegt, kann sie zurückgegeben werden, ohne die autoritativen Nameserver zu kontaktieren. Wenn der zwischengespeicherte Eintrag abläuft, kann der Resolver das autoritative DNS-System abfragen und die aktualisierte Antwort speichern.

Caching reduziert die Suchzeit und die Belastung der DNS-Infrastruktur. Es bedeutet auch, dass Änderungen an Datensätzen nicht unbedingt für jeden Resolver zum gleichen Zeitpunkt sichtbar sind. Die alte Antwort bleibt für einen Resolver solange verwendbar, bis sein Cache abläuft oder der Resolver ihn anderweitig aktualisiert.

Verschiedene Benutzer verwenden möglicherweise unterschiedliche rekursive Resolver. Selbst Personen im selben Haushalt können unterschiedliche Antworten sehen, wenn ihre Geräte verschiedene DNS-Dienste, VPNs, Mobilfunknetze oder lokale Caches nutzen.

Was ist TTL in DNS?

TTL steht für Lebensdauer. Es ist ein Wert, der üblicherweise in Sekunden gemessen wird und rekursiven Resolvern mitteilt, wie lange sie einen DNS-Eintrag zwischenspeichern dürfen, bevor sie nach einer aktualisierten Antwort suchen.

Zum Beispiel ein TTL von 3600 bedeutet eine Stunde. Wenn ein Resolver einen Datensatz mit dieser TTL abruft, kann er die Antwort in der Regel bis zu einer Stunde lang weiterverwenden, bevor er sie aktualisieren muss. Eine TTL von 300 bedeutet fünf Minuten.

Die TTL, die nach einer Änderung relevant ist, ist in der Regel die TTL des alten Records, den Resolver bereits zwischengespeichert haben. Das Herabsetzen der TTL unmittelbar vor dem Ändern eines Records kann die Wartezeit für Resolver, die den vorherigen, höheren TTL zwischengespeichert haben, nicht verkürzen. Diese Resolver können weiterhin die alte Antwort verwenden, bis die ursprüngliche Cache-Zeit abläuft.

Für geplante Migrationen reduzieren Administratoren oft im Voraus die TTL, warten lange genug, bis die vorherige TTL abgelaufen ist, und führen dann die DNS-Änderung durch. Nach Stabilisierung der Änderung können sie die TTL wieder erhöhen, um wiederholte Abfragen zu reduzieren. Die geeigneten Werte hängen vom Dienst und dem Änderungsprozess des Betreibers ab.

Warum dauern DNS-Änderungen unterschiedlich lange?

Der häufigste Grund ist, dass Resolver unterschiedliche zwischengespeicherte Kopien haben. Einige haben den Eintrag möglicherweise bereits aktualisiert, während andere weiterhin eine nicht abgelaufene Antwort verwenden. Ein Resolver kann zudem sein eigenes Aktualisierungsverhalten anwenden oder negative Antworten zwischenspeichern, also Antworten, die darauf hinweisen, dass ein Eintrag nicht existiert.

Lokales Caching kann eine weitere Ebene hinzufügen. Ein Computer, Router, Browser oder Sicherheitsanwendung kann DNS-Informationen vorübergehend speichern. Das Neustarten eines Browsers oder das Löschen des DNS-Caches des Betriebssystems kann in einigen Fällen helfen, ändert jedoch nicht die Informationen, die ein rekursiver Resolver noch zwischengespeichert hat.

DNS-Provider-Änderungen können zusätzliche zeitliche Faktoren einführen. Wenn Sie die autoritativen Nameserver der Domain beim Registrar ändern, müssen Resolver möglicherweise sowohl die Delegierungsinformationen aktualisieren als auch die von diesen Nameservern bereitgestellten Datensätze. Dies ist eine andere Art von Änderung als das Bearbeiten eines A- oder AAAA-Datensatzes innerhalb desselben DNS-Hostingdienstes.

Schließlich kann ein Update an der autoritativen Quelle nicht korrekt sein. Wenn der falsche Datensatz bearbeitet wurde, die Änderung nicht gespeichert wurde, die Domain andere autoritative Nameserver verwendet oder der Datensatz einen Syntaxfehler enthält, wird das Warten die zugrunde liegende Konfiguration nicht beheben.

DNS-Propagierung vs. autoritative DNS-Aktualisierungen

Ein autoritativer DNS-Server stellt die offiziellen Datensätze für eine Domain oder Zone bereit. Wenn Sie einen Eintrag im Kontrollfeld Ihres DNS-Anbieters bearbeiten, sollte der Anbieter die autoritativen Daten aktualisieren, die er bereitstellt.

Ein rekursiver Resolver stellt DNS-Antworten an Clientgeräte bereit. Er kann zwischengespeicherte Daten vor der Änderung enthalten. Daher kann der autoritative Server die neue Adresse zurückgeben, während ein rekursiver Resolver weiterhin eine ältere zurückgibt.

Diese Unterscheidung ist bei der Fehlersuche hilfreich. Überprüfen Sie zunächst, was die autoritativen Nameserver zurückgeben. Wenn diese bereits den erwarteten Record enthalten, wurde die Änderung an der Quelle veröffentlicht, und verbleibende Unterschiede sind wahrscheinlich auf Caching oder das Verhalten des Resolvers zurückzuführen. Wenn die autoritativen Server weiterhin den alten Wert oder keinen Wert zurückgeben, untersuchen Sie die Konfiguration des DNS-Anbieters sowie die Records selbst.

Das Ändern der Nameserver fügt eine weitere Ebene hinzu. Die übergeordnete DNS-Zone muss auf die beabsichtigten autoritativen Nameserver verweisen, und diese Server müssen die korrekte Zone bereitstellen. Ein korrekter Eintrag bei einem DNS-Anbieter ist nicht hilfreich, wenn die Domain an die Nameserver eines anderen Anbieters delegiert ist.

Häufige DNS-Änderungen und ihre Auswirkungen

Ändern eines Ein Rekord changes the IPv4 address returned for a hostname. Changing an AAAA-Eintrag ändert seine IPv6-Adresse. Wenn beide vorhanden sind, können Clients je nach Netzwerk und Verbindungsverhalten entweder die eine oder die andere Adressfamilie verwenden.

Ändern einer CNAME-Eintrag Ändert den Hostnamen, auf den ein Alias verweist. Resolver müssen dann möglicherweise den Zielnamen und dessen Adresse auflösen. Eine Änderung an den Datensätzen des Ziels kann das Endergebnis beeinflussen, selbst wenn der CNAME selbst unverändert bleibt.

Ändern eines MX-Eintrag beeinflusst, welche Mailserver E-Mails für eine Domain empfangen. Mailsysteme können diese Einträge zwischenspeichern, und die E-Mail-Routing-Updates können Zeit benötigen, um wirksam zu werden. Beim Wechsel des Mailanbieters sollten Administratoren MX-Einträge sowie alle damit verbundenen Mail-Authentifizierungseinträge wie SPF, DKIM oder DMARC separat überprüfen.

Änderung Nameserver Änderungen, welcher DNS-Anbieter für die Domain autoritativ ist. Dies erfordert eine korrekte Delegierung beim Registrar und eine korrekte Zonenkonfiguration beim neuen Anbieter. Eine Nameserver-Migration sollte sorgfältig geplant werden, da fehlende Einträge beim neuen Anbieter dazu führen können, dass Websites, E-Mail oder andere Dienste nicht verfügbar sind.

So prüfen Sie, ob eine DNS-Änderung wirksam geworden ist

Beginnen Sie damit, die Domäne vom Computer abzufragen, den Sie verwenden. Unter Windows, macOS und Linux nslookup ist allgemein verfügbar:

nslookup example.com

Um einen IPv4-Adress-Eintrag zu überprüfen, verwenden Sie:

nslookup -type=A example.com

Für IPv6:

nslookup -type=AAAA example.com

Für Mail-Server-Einträge:

nslookup -type=MX example.com

Unter macOS und Linux, dig liefert detailliertere Ausgaben:

dig example.com A

Um nur den Antwortbereich anzuzeigen:

dig example.com A +noall +answer

Sie können einen bestimmten rekursiven Resolver abfragen, um Antworten zu vergleichen. Zum Beispiel:

dig @1.1.1.1 example.com A

Unter Windows können Sie einen DNS-Server wie folgt angeben:

nslookup example.com 1.1.1.1

Ersetzen example.com mit Ihrer Domain. Die Resolver-Adresse in diesen Beispielen ist nur eine mögliche öffentliche Resolver; Sie können auch den DNS-Dienst abfragen, der von Ihrer Organisation oder Ihrem Anbieter verwendet wird.

Notieren Sie den Resolver, den Sie abgefragt haben, die Antwort und die Zeit. Der Vergleich von Ergebnissen mehrerer Resolver hilft dabei zu bestimmen, ob der Unterschied lokal auf einen Resolver beschränkt ist oder weiter verbreitet auftritt.

So fragen Sie einen autoritativen Nameserver

Um die autoritativen Nameserver für eine Domain zu finden, verwenden Sie:

dig example.com NS

Dann fragen Sie einen dieser Nameserver direkt nach dem von Ihnen geänderten Datensatz:

dig @ns1.example-dns.com example.com A

Ersetzen ns1.example-dns.com mit einem autoritativen Server, der für Ihre Domain aufgeführt ist. Wenn die direkte Abfrage die erwartete Adresse zurückgibt, ein rekursiver Resolver jedoch die alte Adresse liefert, sind die autoritativen Daten aktualisiert und der Resolver verwendet möglicherweise weiterhin eine zwischengespeicherte Antwort.

Sie können auch fragen dig den Delegationsprozess nachverfolgen:

dig +trace example.com

Dies folgt der DNS-Hierarchie von der Root-Ebene hin zu den autoritativen Servern der Domain. Es kann helfen, Delegierungsprobleme zu identifizieren, wobei die Ausgabe detaillierter ist als die meisten grundlegenden Prüfungen erfordern.

Wenn Sie das Kontrollfeld eines DNS-Anbieters verwenden, stellen Sie sicher, dass die Domain tatsächlich den dort angezeigten Nameservern zugewiesen ist. Ein Record kann im Dashboard eines Anbieters korrekt sein, während die öffentliche Domain auf einen anderen Anbieter verweist.

Was passiert, wenn einige Benutzer die alte Website sehen?

Stellen Sie zunächst sicher, dass der autoritative A- oder AAAA-Eintrag den beabsichtigten Wert hat. Fragen Sie dann mehrere rekursive Resolver ab und prüfen Sie, ob sie dieselbe Antwort zurückgeben. Wenn die autoritativen Daten korrekt sind, einige Resolver jedoch eine ältere Adresse zurückgeben, ist Caching eine wahrscheinliche Erklärung.

Prüfen Sie als Nächstes die lokale Konfiguration des Benutzers. Ein VPN, der DNS-Resolver des Unternehmens, ein Sicherheitsprodukt, der Browser-Cache oder die lokale Hosts-Datei können beeinflussen, welche Adresse zurückgegeben wird. Vergleichen Sie das Ergebnis aus einem anderen Netzwerk, beispielsweise einer mobilen Verbindung, um festzustellen, ob sich das Verhalten ändert.

Berücksichtigen Sie auch, ob sowohl der alte als auch der neue Server antworten. Eine Migration kann inkonsistent erscheinen, wenn der alte Host weiterhin eine zwischengespeicherte Kopie bereitstellt oder anders weiterleitet. Der DNS-Eintrag kann korrekt sein, während der alte Server für Benutzer noch erreichbar ist, deren Resolver den Eintrag nicht aktualisiert hat.

Wenn das Problem nur IPv4 oder nur IPv6 betrifft, vergleichen Sie die A- und AAAA-Einträge separat. Ein Gerät kann sich über IPv6 verbinden, während ein anderes IPv4 verwendet. Eine Adressfamilie kann auf den neuen Server verweisen, während die andere noch auf den alten verweist.

Was passiert, wenn eine Website nach einer DNS-Änderung nicht verfügbar ist?

Stellen Sie sicher, dass die autoritativen Nameserver der Domain korrekt und erreichbar sind. Überprüfen Sie anschließend, ob die relevanten Datensätze auf diesen Servern vorhanden sind. Wenn Sie kürzlich Nameserver geändert haben, stellen Sie sicher, dass der neue DNS-Anbieter alle erforderlichen Datensätze enthält, einschließlich Website-, E-Mail-, Verifizierungs- und Servicedatensätze.

Stellen Sie sicher, dass der Zielserver bereit ist, Verbindungen für die Domain anzunehmen. Das Aktualisieren von DNS ändert nur, wohin Clients weitergeleitet werden. Es konfiguriert nicht den Webserver, installiert kein Zertifikat, öffnet keine Firewall-Ports oder kopiert Website-Dateien.

Wenn DNS die erwartete IP-Adresse zurückgibt, die Website jedoch weiterhin fehlschlägt, testen Sie den Server und die Anwendung separat. Das Problem kann beim Webserver, der Firewall, dem TLS-Zertifikat, der Hosting-Konfiguration oder der Anwendung liegen. Eine DNS-Suche bestätigt die Namensauflösung; sie bestätigt nicht, dass der Dienst gesund ist.

Für eine allgemeine Pfadprüfung zwischen Ihrem Gerät und einem Ziel sehen Sie sich unseren Leitfaden zu Verwendung von traceroute zur Diagnose von NetzwerkverbindungsproblemenTraceroute und DNS-Lookups testen verschiedene Teile der Verbindung, daher sind sie bei der Eingrenzung eines Problems in Kombination nützlich.

Negatives Caching und „Datensatz nicht gefunden“-Ergebnisse

Resolver können die Tatsache zwischenspeichern, dass ein Datensatz nicht existiert. Dies wird als negative Zwischenspeicherung bezeichnet. Wenn ein Resolver einen Namen abfragt, bevor der Datensatz erstellt wurde, kann es vorübergehend weiterhin eine „Nicht gefunden“-Antwort zurückgeben, auch nachdem der Datensatz hinzugefügt wurde.

Negatives Caching hat ebenfalls eine TTL, basierend auf Informationen aus dem SOA-Eintrag der Zone und den Resolver-Regeln. Das genaue Verhalten kann variieren. Wenn ein neu erstellter Subdomain nicht sofort aufgelöst wird, überprüfen Sie zuerst den autoritativen Nameserver. Wenn dieser den neuen Eintrag zurückgibt, warten Sie, bis die negativen Caches ablaufen, und vergleichen Sie andere Resolver.

Eine Antwort „Datensatz nicht gefunden“ kann auch darauf hinweisen, dass der Datensatz in der falschen Zone hinzugefügt wurde, der Hostname falsch eingegeben wurde oder die Domain andere autoritative Nameserver verwendet. Bestätigen Sie den vollständigen Hostnamen, den Record-Typ und den DNS-Anbieter, bevor Sie davon ausgehen, dass das Problem lediglich auf eine Verzögerung bei der Propagierung zurückzuführen ist.

So planen Sie eine DNS-Migration

Bevor Sie Datensätze für einen Produktionsdienst ändern, listen Sie alle Hostnamen auf und dokumentieren Sie die Dienste, von denen sie abhängen. Eine Website kann A- und AAAA-Datensätze verwenden, während E-Mails von MX-, SPF-, DKIM- und DMARC-Datensätzen abhängen. Anwendungen können auch Verifizierungs- oder Service-Discovery-Datensätze benötigen.

Wenn die Änderung geplant ist, reduzieren Sie die relevante TTL im Voraus und warten Sie mindestens die vorherige TTL-Periode ab, bevor Sie das Ziel wechseln. Bereiten Sie den neuen Server oder Anbieter vor der DNS-Aktualisierung vor. Testen Sie ihn direkt, wo immer möglich, und stellen Sie sicher, dass Zertifikate, Firewall-Regeln, Anwendungseinstellungen und Maildienste bereit sind.

Überprüfen Sie nach der Änderung die autoritativen Antworten und mehrere rekursive Resolver. Überwachen Sie die Verfügbarkeit von Websites, die Zustellung von E-Mails und Anwendungsfehler. Halten Sie den alten Dienst während des Übergangs so weit wie möglich verfügbar, da einige Benutzer ihn weiterhin erreichen können, solange zwischengespeicherte Antworten ablaufen.

Sobald die neue Konfiguration stabil ist, stellen Sie eine geeignete TTL wieder her. Das dauerhafte Beibehalten einer sehr niedrigen TTL kann das DNS-Abfragevolumen erhöhen, ohne einem Dienst, der sich selten ändert, einen nennenswerten Nutzen zu bieten.

Häufige Missverständnisse bei der DNS-Propagation

Ein häufiges Missverständnis ist, dass jede DNS-Änderung genau 24 oder 48 Stunden dauert. Es gibt keine feste, universelle Dauer. Die effektive Verzögerung hängt von den vorherigen TTL-Werten, dem Resolver-Caching, Delegierungsänderungen und der Korrektheit der autoritativen Konfiguration ab.

Ein weiteres Missverständnis ist, dass das Löschen des Browser-Caches die DNS-Einträge überall aktualisiert. Es kann zwar Informationen löschen, die auf diesem Gerät gespeichert sind, aber es kann den Cache eines entfernten rekursiven Resolver nicht leeren. Ebenso kann das Neustarten eines Routers dessen lokalen Cache löschen, ändert jedoch keine autoritativen Datensätze.

Ein drittes Missverständnis besteht darin, dass ein DNS-Checker, der unterschiedliche Antworten anzeigt, beweist, dass die Domain defekt ist. Unterschiedliche Antworten können während einer geplanten Migration auftreten, insbesondere wenn Resolver zu verschiedenen Zeitpunkten zwischengespeicherte Daten haben. Die wichtige Frage ist, ob die autoritativen Datensätze korrekt sind und ob die verbleibenden Unterschiede mit der vorherigen TTL übereinstimmen.

Schließlich konfiguriert die DNS-Propagation nicht den Zielservice. Eine korrekte IP-Adresse kann dennoch zu einer nicht verfügbaren Website führen, wenn der Server, die Firewall, das TLS-Zertifikat oder die Anwendung nicht bereit sind.

Häufig gestellte Fragen zur DNS-Propagation

Wie lange dauert die DNS-Propagierung?

Es gibt keine garantierte Dauer. Einige Änderungen zeigen sich schnell, während andere inkonsistent bleiben, bis zwischengespeicherte Datensätze abgelaufen sind. Die vorherige TTL, das Verhalten des Resolver und die Frage, ob sich die Nameserver geändert haben, beeinflussen alle den Zeitpunkt.

Macht das Herabsetzen der TTL die Änderung sofort wirksam?

Nr. Das Herabsetzen einer TTL wirkt sich auf das zukünftige Caching aus, nachdem Resolver die neue TTL abgerufen haben. Resolver, die den alten Eintrag bereits zwischengespeichert haben, können ihn weiterhin verwenden, bis seine vorherige TTL abläuft.

Warum zeigen DNS-Checker unterschiedliche Ergebnisse?

Sie können verschiedene rekursive Resolver von unterschiedlichen Standorten abfragen. Diese Resolver können unterschiedliche zwischengespeicherte Antworten haben, zu verschiedenen Zeitpunkten aktualisiert werden oder aufgrund geografischer DNS-Richtlinien unterschiedliche Antworten erhalten.

Sollte ich den DNS-Cache meines Computers leeren?

Es kann hilfreich sein, wenn Ihr eigenes Gerät eine veraltete Antwort zwischengespeichert hat. Es löscht keine von Ihrem Internetanbieter, Firmenserver oder öffentlichen DNS-Dienst gehaltenen Caches.

Warum wird meine Website aufgelöst, lädt aber trotzdem nicht?

DNS kann die korrekte Adresse zurückgeben, während der Zielserver oder die Anwendung ein Problem aufweist. Überprüfen Sie den Webserver, die Firewall, das TLS-Zertifikat und die Hosting-Konfiguration separat.

Können Änderungen an Nameservern länger dauern als Änderungen an Records?

Sie können zusätzliche Delegierungsinformationen beim Registrar und in der übergeordneten DNS-Zone umfassen. Der neue Anbieter muss außerdem eine vollständige und korrekte Zone bereitstellen. Überprüfen Sie sowohl die Delegierung als auch die Einträge auf den neuen autoritativen Servern.

DNS-Änderungen können zu unterschiedlichen Zeitpunkten wirksam werden, da autoritative Nameserver und rekursive Resolver unterschiedliche Rollen haben und Resolver Antworten gemäß den TTL-Werten zwischenspeichern. Ein Benutzer kann möglicherweise noch eine alte Adresse sehen, während ein anderer bereits die neue erhält.

Führen Sie zur Untersuchung zunächst eine Überprüfung der autoritativen Nameserver durch und vergleichen Sie anschließend die Antworten mehrerer rekursiver Resolver. Bestätigen Sie den Record-Typ, den Hostnamen, die TTL (Time to Live) und die Nameserver-Delegation. Wenn DNS die erwartete Adresse zurückgibt, der Dienst jedoch weiterhin nicht verfügbar ist, prüfen Sie den Zielserver und die Anwendung als separate Teile des Problems.

Das Verständnis von Caching erleichtert die Planung und Fehlerbehebung bei DNS-Änderungen. Für weitere Grundlagen der Netzwerktechnik lesen Sie unsere Anleitungen zu IP-Adressen, Standard-Gateways, und traceroute.