DNS-Propagation und TTL: Warum Änderungen Zeit brauchen

Wer einen DNS-Eintrag ändert und erwartet, dass sofort alle den neuen Wert sehen, wird oft enttäuscht. Stattdessen zeigt der eine Browser bereits den neuen Server, ein anderer noch den alten. Dieses Phänomen heißt DNS-Propagation und hängt eng mit einem Wert namens TTL zusammen. Dieser Artikel erklärt, warum das so ist und wie Sie Änderungen planbar machen.

Warum DNS-Änderungen nicht sofort wirken

Das Domain Name System ist auf Geschwindigkeit und Entlastung der autoritativen Server ausgelegt. Müsste jeder Aufruf einer Webseite eine vollständige Abfrage bis zum zuständigen Nameserver auslösen, entstünde enorme Last und spürbare Verzögerung. Deshalb speichert nahezu jede Station auf dem Weg einer Anfrage die erhaltene Antwort zwischen. Dieses Zwischenspeichern nennt man Caching.

Caching ist der Grund, warum eine Änderung Zeit braucht. Solange ein Cache eine gültige, noch nicht abgelaufene Antwort besitzt, liefert er diese aus, ohne erneut beim autoritativen Server nachzufragen. Erst wenn die gespeicherte Antwort als veraltet gilt, wird neu abgefragt. Wie lange eine Antwort als gültig gilt, bestimmt die TTL.

Caching auf mehreren Ebenen

Eine DNS-Antwort durchläuft auf dem Weg zum Nutzer mehrere Stationen, von denen jede einen eigenen Cache führen kann. Das erklärt, warum Änderungen ungleichmäßig ankommen.

Die wichtigste Ebene ist der rekursive Resolver des Providers oder eines öffentlichen Dienstes. Er bedient sehr viele Nutzer aus einem gemeinsamen Cache. Solange dieser Cache den alten Wert hält, sehen alle dahinterliegenden Nutzer den alten Wert, unabhängig davon, was im autoritativen Nameserver bereits eingetragen ist.

Die TTL ist eine Obergrenze für die Cache-Dauer, an die sich nicht jeder Resolver strikt hält.

Die Rolle der TTL

Die TTL, ausgeschrieben Time to Live, ist ein Zahlenwert in Sekunden, der zu jedem DNS-Eintrag gehört. Sie sagt einem Resolver: Diese Antwort darfst du so viele Sekunden lang aufbewahren und ausliefern, danach musst du neu fragen. Ein A-Record mit einer TTL von 3600 darf also eine Stunde lang aus dem Cache beantwortet werden. Was ein Lookup bei einem Resolver anzeigt, ist die Restlaufzeit dieser Zeitspanne und nicht der Wert aus der Zone.

Niedrige TTLs sorgen für schnelle Änderungen, erzeugen aber mehr Abfragen, weil Caches häufiger neu nachfragen müssen. Hohe TTLs entlasten die Nameserver und beschleunigen Auflösungen, machen Änderungen aber träge. In der Praxis sind Werte zwischen 300 und 86400 Sekunden üblich.

Wichtig ist: Eine TTL-Senkung wirkt erst, nachdem der alte, höhere TTL-Wert abgelaufen ist. Wenn ein Eintrag bisher eine TTL von 86400 Sekunden hatte und Sie diese auf 300 senken, kann ein Resolver den Eintrag trotzdem noch fast einen Tag lang mit der alten Information behalten. Deshalb muss die Senkung rechtzeitig vor der eigentlichen Änderung erfolgen.

Ein verbreitetes Missverständnis betrifft die Frage, ab wann die TTL überhaupt zu zählen beginnt. Der Zähler startet nicht beim Eintragen des Werts im Nameserver, sondern in dem Moment, in dem ein Resolver die Antwort tatsächlich abruft und in seinen Cache legt. Holt sich ein Resolver den alten Eintrag eine Sekunde vor Ihrer Änderung, läuft bei ihm die volle TTL ab, bevor er den neuen Wert sieht. Genau diese zeitliche Streuung über viele Resolver hinweg lässt die Propagation als allmählichen Übergang erscheinen und nicht als scharfen Schnitt.

Zu beachten ist außerdem, dass die TTL je Eintragstyp getrennt gilt. Ein A-Record kann eine niedrige TTL besitzen, während der zugehörige MX-Record für die Mailzustellung eine hohe TTL trägt. Stellen Sie nur den A-Record um, ist die Webseite schnell auf dem neuen Server, die Mailzustellung folgt aber erst, wenn der separate MX-Record propagiert ist. Planen Sie Umzüge daher record-spezifisch und nicht pauschal für die ganze Domain.

Wie lange Propagation tatsächlich dauert

Theoretisch ist eine Änderung nach Ablauf der TTL überall sichtbar. Bei einzelnen Einträgen ist die Wartezeit durch die alte TTL begrenzt, sofern sich die Resolver daran halten. Manche verlängern oder verkürzen sie aus eigenen Gründen. Zudem haben verschiedene Caches zu unterschiedlichen Zeitpunkten ihre Antwort geholt, sodass sie auch zu unterschiedlichen Zeitpunkten ablaufen. Die oft genannten 24 bis 48 Stunden stammen vor allem von Nameserver-Wechseln, bei denen die Delegations-TTL der Registry den Takt vorgibt.

Ein Sonderfall ist der Wechsel der Nameserver selbst. Hier ändern Sie nicht nur einzelne Records, sondern delegieren die gesamte Zone an andere Server. Welche Nameserver zuständig sind, steht in der Delegation: Die NS-Einträge liegen in der Zone der Top-Level-Domain bei der Registry, und ihre TTL legt die Registry fest, nicht Sie und nicht Ihr DNS-Anbieter. Resolver, die die alte Delegation im Cache haben, fragen weiter die alten Nameserver, bis sie abläuft. Solche Wechsel brauchen daher meist länger als das Ändern eines einzelnen A-Records innerhalb derselben Zone, und eine TTL-Senkung beim alten Anbieter wirkt auf die Delegation nicht.

TTL vor dem Umzug senken

Für einen geplanten Wechsel der Server-IP, also die Änderung eines Eintrags innerhalb der Zone, besteht die bewährte Strategie aus drei Schritten und nutzt die TTL gezielt aus.

1. Senken Sie die TTL des betroffenen Eintrags mehrere Tage vor dem Umzug auf einen niedrigen Wert wie 300 Sekunden. Warten Sie, bis die bisherige hohe TTL vollständig abgelaufen ist, sonst wirkt die Senkung verzögert.
2. Führen Sie die eigentliche Änderung durch, etwa das Umstellen des A-Records auf die neue Server-IP. Dank der niedrigen TTL übernehmen die Resolver den neuen Wert nun innerhalb weniger Minuten.
3. Erhöhen Sie die TTL nach erfolgreicher Umstellung wieder auf einen normalen Wert wie 3600 oder höher, um die Nameserver zu entlasten.

Propagation prüfen

Ob eine Änderung angekommen ist, lässt sich nicht an einem einzigen Gerät ablesen, denn Ihr eigener Cache kann Sie täuschen. Aussagekräftiger ist der Vergleich mehrerer Resolver. Unser Lookup bietet zwei zur Auswahl, Google Public DNS und Cloudflare. Stimmen deren Antworten überein und entsprechen dem neuen Wert, ist die Änderung bei diesen beiden Resolvern angekommen. Das ist ein guter Hinweis, aber keine Garantie für alle anderen Resolver, etwa den Ihres Providers. Für gezielte Abfragen bestimmter Server sind dig oder nslookup auf der Kommandozeile geeignet.

Mit unserem DNS-Lookup fragen Sie Einträge über DNS-over-HTTPS ab und sehen die jeweils gemeldete TTL direkt mit. Sie ist die Restlaufzeit im Cache des Resolvers. Sinkt sie bei wiederholten Abfragen und springt sie nach Ablauf auf den Zonenwert zurück, beobachten Sie das Cache-Verhalten. Bei großen Anbietern antworten mehrere Cache-Instanzen, deshalb kann der Wert zwischen zwei Abfragen auch einmal springen. Vertiefende Anleitungen finden Sie unter TTL verstehen und Propagation prüfen.

Wenn Ihr lokaler Rechner noch den alten Wert zeigt, hilft das Leeren des Betriebssystem-Caches. Unter Windows leert ipconfig /flushdns den Resolver-Cache, unter Linux je nach Dienst etwa resolvectl flush-caches. Den Browser-Cache umgehen Sie am einfachsten durch einen Neustart des Browsers. Beachten Sie aber, dass diese lokalen Maßnahmen nur Ihren eigenen Rechner betreffen. Der Cache des Provider-Resolvers, der die eigentliche Verzögerung verursacht, bleibt davon unberührt und läuft erst nach Ablauf seiner TTL ab.

Häufige Stolpersteine bei der Umstellung

In der Praxis scheitert eine saubere Umstellung selten an der TTL selbst, sondern an Begleitfehlern. Ein typischer Fall ist die zu spät gesenkte TTL: Wer die Senkung erst kurz vor dem Umzug einträgt, profitiert nicht davon, weil die alten, hohen TTLs in den Caches noch gelten. Die Senkung muss den vollen alten TTL-Zeitraum Vorlauf bekommen, um überhaupt zu greifen.

Ein zweiter Stolperstein ist das vorzeitige Abschalten des alten Servers. Solange auch nur ein einziger Resolver noch den alten Wert ausliefert, erreichen dessen Nutzer den alten Server. Schalten Sie ihn zu früh ab, sehen diese Nutzer eine Fehlermeldung, obwohl der neue Server längst läuft. Halten Sie den alten Server daher mindestens so lange erreichbar, wie die ursprüngliche TTL plus ein Sicherheitspuffer es nahelegen.

Drittens sorgt das Vergessen abhängiger Einträge für Probleme. Wird ein A-Record umgezogen, der per CNAME von anderen Namen referenziert wird, müssen diese Beziehungen mitbedacht werden. Eine Inventarliste aller relevanten Records vor dem Umzug verhindert, dass einzelne Subdomains oder Dienste übersehen werden.

Was Sie aus der Wartezeit mitnehmen

DNS-Propagation ist kein Fehler, sondern die direkte Folge eines bewusst zwischenspeichernden Systems. Wer die TTL versteht, kann die Wartezeit steuern statt sie zu erleiden. Senken Sie die TTL rechtzeitig, wenn sich ein Wert ändert, halten Sie bei Nameserver-Wechseln beide Seiten parallel vor und vergleichen Sie mehrere Resolver statt nur den eigenen Rechner. Mehr Grundlagen liefert der Artikel Was ist DNS?, und wer seine Zustellbarkeit absichern will, findet im Beitrag DNS-Sicherheit die passenden Schutzmaßnahmen.