DNS-Propagation erklärt: Warum DNS-Änderungen dauern und wie du sie prüfst

DNS-Propagation ist die Zeit, die vergeht, bis eine DNS-Änderung überall sichtbar ist. Sie wird ausschließlich durch TTL-Caching (Time To Live) bestimmt, nicht durch irgendeine globale Verteilung oder Synchronisierung. Es gibt keinen einzelnen Moment, in dem eine Änderung weltweit „live geht“: Verschiedene Resolver übernehmen sie zu unterschiedlichen Zeitpunkten, je nachdem, was sie bereits im Cache haben und wie lange.

Wenn du das verstanden hast, verlieren DNS-Änderungen viel von ihrem Mysterium. Sobald du weißt, was die Verzögerung tatsächlich steuert, kannst du Änderungen so planen, dass sie vorhersehbar ausgerollt werden, statt zu raten und ständig den Browser neu zu laden.

Was bedeutet „DNS-Propagation“ eigentlich?

Der Begriff ist nicht Teil einer formalen DNS-Spezifikation. Er ist eine in der Branche übliche Kurzform für die Verzögerung zwischen der Aktualisierung eines Eintrags auf deinem autoritativen Nameserver und dem Zeitpunkt, an dem jeder Resolver weltweit diese Aktualisierung widerspiegelt. Jeder Resolver, der deine Domain abfragt, speichert die Antwort im Cache und liefert diese gecachte Antwort so lange aus, bis seine selbst gesetzte Ablaufzeit vorbei ist.

„Propagation“ ist also nichts, was mit deinem Eintrag passiert. Sie ist die natürliche Nebenwirkung davon, dass Tausende unabhängiger Caches auf der ganzen Welt jeweils nach ihrem eigenen Zeitplan entscheiden, wann sie erneut nachfragen.

Der eigentliche Treiber: die TTL

Jeder DNS-Eintrag trägt einen TTL-Wert in Sekunden, den derjenige festlegt, der die Zone verwaltet. Die TTL teilt jedem Resolver, der den Eintrag cacht, mit: „Du darfst diese Antwort so viele Sekunden lang wiederverwenden, bevor du beim autoritativen Server erneut nachfragen musst.“ Dieses Verhalten ist in RFC 1035 definiert. RFC 2181 stellte später klar, dass alle Einträge desselben Record-Sets eine gemeinsame TTL haben müssen und dass Resolver immer die niedrigste TTL berücksichtigen sollen, die sie für dieses Set gesehen haben.

Einige gängige TTL-Werte und was sie in der Praxis bedeuten:

Niedrigere TTLs bedeuten schnellere Propagation, aber mehr Anfragen an dein autoritatives DNS. Höhere TTLs bedeuten weniger Anfragen und eine bessere Caching-Performance, aber einen langsameren Rollout, wenn du dringend etwas ändern musst. Wenn du nicht sicher bist, was aktuell für einen Eintrag eingestellt ist, zeigt dir unser DNS-Lookup-Tool die aktuelle TTL zusammen mit dem Wert an.

Die TTL-Falle, in die fast jeder einmal tappt

Hier kommt der Punkt, an dem viele stolpern: Eine gesenkte TTL greift erst, nachdem die vorherige, längere TTL abgelaufen ist. Wenn dein A-Eintrag aktuell eine TTL von 24 Stunden hat und du sie auf 300 Sekunden änderst, verwenden Resolver, die den Eintrag bereits unter der alten TTL gecacht haben, diese gecachte Kopie – und den alten TTL-Wert – bis zu 24 Stunden weiter, bevor sie erneut nachfragen und die neue, kürzere TTL bemerken.

Die richtige Reihenfolge für jede DNS-Änderung, bei der dir das Timing wichtig ist, lautet deshalb:

1. Senke die TTL des Eintrags einige Tage vor der eigentlichen Änderung (auf etwa 300 Sekunden).
2. Warte, bis die alte TTL überall vollständig abgelaufen ist – gib ihr die volle alte Dauer, nicht die neue.
3. Nimm die eigentliche Änderung vor (neue IP, neues CNAME-Ziel oder was auch immer).
4. Sobald die Änderung propagiert ist und sich gesetzt hat, erhöhe die TTL wieder, wenn du den Caching-Vorteil zurückhaben willst.

TipSchritt 1 zu überspringen ist der häufigste Grund, warum sich ein DNS-„Cutover“ ewig hinzuziehen scheint – der Eintrag, den du gerade bearbeitet hast, war nie der Engpass, sondern die TTL von vor deiner Änderung.

Warum Nameserver-Änderungen länger dauern als Änderungen an DNS-Einträgen

Das Ändern eines einzelnen A-, CNAME- oder MX-Eintrags innerhalb deiner bestehenden DNS-Zone ist eine Änderung auf Eintragsebene – sie wird ausschließlich durch die TTL dieses Eintrags gesteuert. Eine Domain an komplett neue Nameserver zu delegieren ist etwas anderes: Das ist eine Änderung in der übergeordneten Zone (bei der Registry), und dieser Delegationseintrag hat eine eigene TTL, die von der Registry festgelegt wird und nicht von dir.

Weil sich die Aktualisierungsintervalle auf Registry-Ebene und das Caching der übergeordneten Zone zu den TTLs deiner eigenen Zone addieren, geben Anbieter für Änderungen an der Nameserver-Delegation (NS) häufig bis zu 24–48 Stunden an, wobei der genaue Wert je nach TLD (Top-Level-Domain) und Registry variiert. Plane Nameserver-Migrationen mit diesem längeren Zeitfenster und vermeide es, im selben Zeitraum andere dringende DNS-Änderungen vorzunehmen.

Negatives Caching: Warum auch ein fehlender DNS-Eintrag Zeit braucht

Wenn ein Resolver nach einem Eintrag fragt, der noch nicht existiert – etwa weil du den A-Eintrag einer Subdomain noch nicht angelegt hast –, cacht der Resolver auch diese negative Antwort. Das nennt sich negatives Caching und ist in RFC 2308 geregelt, das die negative TTL an das MINIMUM-Feld des SOA-Eintrags (Start of Authority) deiner Zone koppelt.

In der Praxis heißt das: Wenn du eine Subdomain abfragst, bevor sie existiert, eine NXDOMAIN-Antwort erhältst und den Eintrag fünf Minuten später anlegst, antworten manche Resolver womöglich weiterhin mit dem alten „existiert nicht“, bis dieser negative Cache-Eintrag abläuft. Es ist derselbe zugrunde liegende Mechanismus wie beim normalen TTL-Caching, nur auf das Fehlen statt auf das Vorhandensein angewendet.

DNS-Propagation richtig prüfen

Die zuverlässigste Prüfung ist, die autoritativen Nameserver direkt abzufragen, denn sie haben immer die aktuelle Antwort – die Verzögerung existiert nur in den Caches aller anderen, nicht in der maßgeblichen Quelle.

dig +trace example.com A
dig @ns1.yourprovider.com example.com A

Alternativ kannst du mit unserem DNS-Lookup-Tool den aktuellen Eintrag direkt aus dem DNS abrufen, die tatsächlich gesetzte TTL prüfen und bestätigen, dass der Wert deiner Änderung entspricht. Wenn er noch nicht übereinstimmt, ist das normal – es bedeutet nur, dass der Resolver, den du abfragst, seit deiner Änderung noch nicht erneut nachgefragt hat, nicht, dass etwas kaputt ist.

Einige praktische Prüfungen, die sich nach jeder DNS-Änderung lohnen:

• Frage über mehr als einen Resolver ab (den deines Internetanbieters plus einen öffentlichen wie Google oder Cloudflare) – sie cachen unabhängig voneinander, daher siehst du während der Propagation unterschiedliche Stände.
• Prüfe neben dem Wert auch die TTL, nicht nur den Wert – eine veraltet wirkende Antwort mit niedriger Rest-TTL korrigiert sich in Kürze von selbst.
• Wenn du MX- oder SPF-Einträge verwaltest, prüfe sie mit dem MX-Lookup oder dem SPF-Generator, statt davon auszugehen, dass E-Mail-Anbieter die Änderung übernommen haben – die vollständige Syntax findest du in unserem Leitfaden zum Erstellen eines sicheren SPF-Eintrags.

WarningBearbeite einen Eintrag nicht panisch immer wieder, während du auf die Propagation wartest. Jede Änderung verändert, was Resolver sehen, sobald sie erneut nachfragen, und wenn du dich mitten in einem TTL-Fenster befindest, sorgen zusätzliche Änderungen nur für mehr Inkonsistenz zwischen den Caches, nicht für weniger.

TTL und DNS-Propagation über mehrere Anbieter hinweg verwalten

Wenn deine Domains, dein DNS und deine Zertifikate auf mehrere Registrare und Clouds verteilt sind, werden Propagationsverzögerungen schwerer nachvollziehbar – du musst unterschiedliche TTL-Standardwerte, unterschiedliches Registrar-Verhalten bei NS-Änderungen und unterschiedliche Tools für jeden Anbieter im Blick behalten. Eine zentrale DNS-Verwaltung macht es viel einfacher, die oben beschriebene TTL-Reihenfolge (senken, warten, ändern, erhöhen) konsequent umzusetzen, weil du TTLs an einer Stelle setzt und prüfst, statt mit mehreren Dashboards zu jonglieren. Unsere DNS-Verwaltung bietet dir diese zentrale Ansicht über alle Anbieter hinweg, zusammen mit einem Änderungsverlauf auf Eintragsebene, damit du genau siehst, was wann gesetzt wurde.

Wenn du dich noch damit vertraut machst, welche Eintragstypen von der TTL betroffen sind und wie sie zusammenspielen, ist unser vollständiger Leitfaden zu DNS-Eintragstypen eine gute Ergänzung zu diesem Artikel. Und wenn du tiefer in die Mechanik einsteigen willst, wie ein Resolver überhaupt eine Antwort findet, lies So funktioniert die DNS-Auflösung.

Wenn du das nächste Mal eine Änderung planst, prüfe zuerst die aktuelle TTL – hier nachschlagen – und plane deinen Rollout danach, statt zu raten.