Du hast einen DNS-Eintrag geändert, die neue Adresse läuft, und die halbe Welt besucht noch die alte. Das ist kein Geist. Das ist die TTL.
Kurz gesagt
Die TTL (Time to Live) eines DNS-Eintrags ist eine Zahl in Sekunden, die sagt, wie lange der Eintrag zwischengespeichert werden darf, bevor man die Quelle der Information erneut fragen sollte [1]. Resolver und Caches auf dem Weg behalten die Antwort, bis die Zeit abläuft, deshalb zeigt sich eine Änderung nach und nach und nicht sofort [1][5]. Unsere Einschätzung: Senke die TTL eine Weile vor einer geplanten Änderung, ändere den Eintrag und erhöhe die TTL danach wieder.
So funktioniert’s
- Ein Countdown. Die Zone hält für jeden Eintrag eine gleichbleibende TTL, zwischengespeicherte Kopien zählen dagegen herunter. Ist der Countdown vorbei, gelten die Daten als abgelaufen und sollen ignoriert werden [1]. Eine TTL von null heißt, dass der Eintrag nur für den laufenden Vorgang genutzt und nicht gespeichert werden darf [1].
- Wertebereich und Bedeutung. RFC 2181 klärte, was STD 13 offen ließ: Eine TTL ist eine vorzeichenlose Zahl von 0 bis 2147483647, also 2^31 − 1 Sekunden. Die TTL gibt eine Höchstdauer an, keine verbindliche Dauer, ein Cache darf also eine eigene Obergrenze setzen [2].
- Eine TTL je Eintragsgruppe. Alle Einträge einer Gruppe, etwa mehrere A-Einträge für denselben Namen, müssen dieselbe TTL haben [2].
- Die Praxis kappt sie. RFC 8767 empfiehlt, TTLs in der Größenordnung von Tagen bis Wochen zu begrenzen, mit 604.800 Sekunden (7 Tage) als empfohlener Grenze [4].
- Veraltete Antworten liefern. Derselbe RFC erlaubt einem Resolver, abgelaufene Daten zu nutzen, wenn er die zuständigen Server nicht erreicht, um sie aufzufrischen. Solche veralteten Einträge gehen mit einer TTL von 30 Sekunden hinaus, und die vorgeschlagene maximale Dauer liegt bei 1 bis 3 Tagen [4].
- Auch negative Antworten haben eine TTL. Bei „Name existiert nicht“ und „keine Daten dieses Typs“ stammt die TTL aus dem SOA-Eintrag, als Minimum aus dessen Feld MINIMUM und seiner eigenen TTL [3]. Legst du einen Eintrag an, der gerade abgefragt wurde und fehlte, sagen manche Caches so lange weiter „existiert nicht“. Das ist unsere Lesart von RFC 2308.
- Anbieter setzen Grenzen. Bei Cloudflare nutzen Einträge mit Proxy immer „Auto“, das sind 300 Sekunden. Für reine DNS-Einträge wählst du zwischen 60 Sekunden (30 Sekunden bei Enterprise) und 1 Tag. Cloudflare weist darauf hin, dass dein lokaler DNS-Cache länger als fünf Minuten brauchen kann, bis er eine Änderung zeigt [5].
- Nachsehen. Das Werkzeug
digzeigt standardmäßig die TTL jedes Eintrags, und+noall +answerbeschränkt die Ausgabe auf den Antwortabschnitt [6].
Ein Praxisbeispiel
Ein Eintrag für nas.example.com hat eine TTL von 3600 Sekunden (eine Stunde). Du willst den Dienst am nächsten Samstag auf eine neue Adresse umziehen. Am Freitag senkst du die TTL auf 300 Sekunden und lässt mindestens die alte TTL, eine Stunde, vor dem Umzug verstreichen, denn ein Resolver, der kurz vor der Änderung gefragt hat, kann die alte Antwort so lange behalten. Am Samstag änderst du die Adresse. Später erhöhst du die TTL wieder. Frag deinen Resolver zweimal im Abstand weniger Sekunden und sieh zu, wie die TTL schrumpft [1][6]:
dig +noall +answer nas.example.comEigene DNS-Einträge haben wir in unserem Inventar (14. bis 16. Okt. 2026) nicht dokumentiert, deshalb sind Namen und Zahlen hier zur Veranschaulichung erfunden.
Prüfliste
- Senke die TTL mindestens eine alte TTL vor der Änderung, und zwar zuerst, nicht gleichzeitig [1][2].
- Denke daran, dass manche Caches und Clients eigene Grenzen setzen und eine TTL ein Höchstwert ist [2][4].
- Rechne nach einem Ausfall mit alten Antworten, denn Resolver dürfen veraltete Daten liefern [4].
- Prüfe die SOA-Werte, wenn „existiert nicht“ nach dem Anlegen eines Eintrags hängen bleibt [3].
- Nimm eine kurze TTL nur dort, wo du sie brauchst, denn längere TTLs machen Abfragen schneller, und erhöhe sie nach dem Umzug wieder [5].
- Teste mit
digund leere deinen lokalen Cache, bevor du die Änderung für gescheitert hältst [5][6].