DNS-Propagierung: Warum Änderungen so lange dauern

Sie haben einen A-Record geändert. Die neue Website lädt auf Ihrem Smartphone, aber nicht auf Ihrem Laptop. Ein Kollege am anderen Ende des Landes sieht noch die alte. Jemand rät Ihnen, „auf die Propagierung zu warten“.

Dieser Begriff führt gezielt in die Irre, und wer ihm glaubt, denkt schlechter über das Problem nach. Nichts wird propagiert. Es werden nirgendwohin Daten verteilt.

Was tatsächlich passiert

Wenn ein Resolver Ihre Domain abfragt, speichert er die Antwort zusammen mit einer TTL – einem Countdown in Sekunden. Bis dieser Countdown null erreicht, antwortet der Resolver aus dem Speicher und kontaktiert Ihren Nameserver nicht erneut.

Wenn Sie also einen Record ändern:

1. Ihr autoritativer Nameserver aktualisiert sich sofort. Er liefert den neuen Wert ab jetzt an jeden, der fragt.
2. Jeder Resolver, der den alten Wert gecacht hat, liefert ihn weiter aus, bis sein eigener Countdown abläuft.
3. Diese Countdowns haben zu unterschiedlichen Zeitpunkten begonnen – wann immer der jeweilige Resolver den Record erstmals abgerufen hat –, deshalb laufen sie zu unterschiedlichen Zeiten ab.
4. Sobald einer abläuft, ruft dieser Resolver den neuen Wert ab. Seine Nutzer wechseln in genau diesem Moment.

Das gestaffelte Ergebnis wirkt wie eine Änderung, die sich „ausbreitet“. In Wirklichkeit laufen einfach viele unabhängige Timer ab.

Wie lange die Wartezeit tatsächlich ist

Die maximale Wartezeit entspricht der TTL, die vor Ihrer Änderung auf dem Record lag. Dieses Detail macht die Propagierung vorhersehbar.

So planen Sie eine DNS-Änderung richtig

1. 1

   Einen Tag vorher: TTL senken

   Setzen Sie die TTL auf 300 Sekunden und ändern Sie sonst nichts. Warten Sie mindestens so lange wie die alte TTL, damit jeder Cache den kürzeren Wert übernimmt.

2. 2

   Prüfen, dass die niedrige TTL aktiv ist

   Führen Sie dig example.com aus und prüfen Sie die TTL im Answer-Abschnitt. Sobald sie von 300 statt von 3600 herunterzählt, laufen alle Resolver auf dem kurzen Timer.

3. 3

   Die eigentliche Änderung vornehmen

   Aktualisieren Sie den Record. Jetzt wartet niemand länger als fünf Minuten statt einer Stunde.

4. 4

   Von mehreren Standpunkten aus verifizieren

   Fragen Sie mehrere öffentliche Resolver direkt ab – sie sind unabhängige Caches und liefern eine echte Stichprobe dessen, was verschiedene Nutzer sehen.

5. 5

   Die TTL wieder erhöhen

   Sobald sich der Traffic auf dem neuen Wert eingependelt hat, setzen Sie die TTL wieder auf 3600 oder höher. Niedrige TTLs bedeuten mehr Abfragen und für alle etwas langsamere Lookups.

Prüfen, was verschiedene Resolver sehen

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

dig +short example.com @ns1.example.com

Dieser letzte Befehl ist der wichtigste. Liefert der autoritative Server den neuen Wert, ist Ihre Änderung korrekt und vollständig. Alles andere ist Warten, nicht Reparieren. Liefert er den alten Wert, wurde die Änderung nicht gespeichert – oder Sie haben sie bei einem Anbieter bearbeitet, an den Ihre Domain nicht delegiert ist.

Warum es auf verschiedenen Geräten anders aussieht

Zwischen Ihnen und der Antwort liegt nicht ein Cache, sondern mehrere, jeder mit eigenem Timer:

• Ihr Browser führt einen kurzen internen DNS-Cache.
• Ihr Betriebssystem führt unabhängig davon einen eigenen.
• Ihr Router cacht häufig für den gesamten Haushalt.
• Der Resolver Ihres Providers cacht potenziell für Millionen von Nutzern.
• Unternehmens- oder VPN-Resolver fügen in verwalteten Netzwerken eine weitere Ebene hinzu.

Ihr Smartphone im Mobilfunknetz nutzt eine völlig andere Resolver-Kette als Ihr Laptop im heimischen WLAN – und genau deshalb zeigt das eine die neue Website und das andere nicht. Die Ebenen, die Sie selbst kontrollieren, können Sie leeren: siehe DNS-Cache leeren.