DNS-Propagation und TTL: Warum Änderungen Zeit brauchen

Wer einen DNS-Eintrag ändert und erwartet, dass die Welt sofort den neuen Wert sieht, 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.

Cache-Ebene	Wer cached	Einfluss auf Propagation
Browser-Cache	Der Webbrowser selbst	Hält Auflösungen kurz vor, ignoriert oft die TTL und nutzt eigene Zeitfenster
Betriebssystem-Cache	Der Resolver-Dienst von Windows, macOS oder Linux	Speichert Antworten lokal, lässt sich gezielt leeren
Router im Heimnetz	Das lokale Gateway oder die Fritzbox	Kann als kleiner Resolver eigene Antworten zwischenspeichern
Resolver des Providers	Der rekursive DNS-Server des Internetanbieters	Größter Hebel, bedient viele Nutzer aus einem gemeinsamen Cache
Öffentliche Resolver	Dienste wie Cloudflare oder Google	Eigene, oft global verteilte Caches mit eigenem Ablaufverhalten

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 kein Versprechen über Sekunden, sondern eine Obergrenze, 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.

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. Praktisch nennt man oft 24 bis 48 Stunden, und das hat mehrere Gründe. Erstens halten sich nicht alle Resolver an die vorgegebene TTL, manche verlängern sie aus eigenen Gründen. Zweitens haben verschiedene Caches zu unterschiedlichen Zeitpunkten ihre Antwort geholt, sodass sie auch zu unterschiedlichen Zeitpunkten ablaufen. Drittens spielen bei einem Nameserver-Wechsel zusätzlich die Aktualisierungsintervalle der zuständigen Registry eine Rolle.

Ein Sonderfall ist der Wechsel der Nameserver selbst. Hier ändern Sie nicht nur einzelne Records, sondern delegieren die gesamte Zone an andere Server. Diese NS-Einträge liegen bei der Registry der Top-Level-Domain und besitzen oft hohe TTLs. Solche Wechsel brauchen daher tendenziell länger als das Ändern eines einzelnen A-Records innerhalb derselben Zone.

TTL vor dem Umzug senken

Die bewährte Strategie für einen geplanten Wechsel besteht 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 eine Abfrage über mehrere unabhängige Resolver. Stimmen deren Antworten überein und entsprechen dem neuen Wert, gilt die Propagation für diese Resolver als abgeschlossen.

Mit unserem DNS-Lookup fragen Sie Einträge über DNS-over-HTTPS ab und sehen die jeweils gemeldete TTL direkt mit. Sinkt die angezeigte TTL bei wiederholten Abfragen und springt sie nach Ablauf auf den vollen Wert zurück, beobachten Sie das Cache-Verhalten in Echtzeit. 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, halten Sie bei Nameserver-Wechseln beide Seiten parallel vor und prüfen Sie über mehrere Resolver statt nur über 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.