Was ist die TTL im DNS? Werte, Caching und wann Sie sie senken

Die TTL („Time to Live“) ist die Zahl an jedem DNS-Eintrag, die festlegt, wie viele Sekunden ein Resolver die Antwort in seinem Cache behalten darf, bevor er erneut fragen muss. Sie ist der einzige echte Hebel dafür, wie schnell eine DNS-Änderung bei den Nutzern ankommt, und der Grund, warum die DNS-Propagation so lange dauert, wie sie dauert.

So funktioniert die TTL

Jeder Eintrag einer Zone trägt eine TTL:

www.example.com.   3600   IN   A   192.0.2.10

Holt ein rekursiver Resolver (der Ihres Internetproviders, Ihres Büros oder ein öffentlicher wie 1.1.1.1 oder 8.8.8.8) diesen Eintrag vom autoritativen Server, speichert er ihn und zählt von 3600 abwärts. Wer diesen Resolver in der folgenden Stunde fragt, bekommt die Kopie aus dem Cache, und zwar mit der verbleibenden TTL. Erreicht der Zähler null, wird der Eintrag verworfen, und die nächste Anfrage löst eine frische Abfrage aus.

Das lässt sich beobachten:

$ dig +noall +answer www.example.com @1.1.1.1
www.example.com.   3412   IN   A   192.0.2.10
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com.   3397   IN   A   192.0.2.10

Die zweite Zahl ist gesunken. Fragen Sie den autoritativen Server direkt, sehen Sie immer den vollen, konfigurierten Wert:

$ dig +noall +answer www.example.com @ns1.dns.example
www.example.com.   3600   IN   A   192.0.2.10

Dieser Unterschied ist ein praktisches Diagnosemittel: Eine TTL unterhalb des konfigurierten Werts bedeutet, dass Sie auf einen Cache schauen.

Aus dem Mechanismus folgen drei Dinge:

Nichts wird verteilt. Die Änderung eines Eintrags benachrichtigt keinen einzigen Resolver. Jeder Cache behält die alte Antwort, bis sein eigener Countdown abgelaufen ist.
Caches laufen zu unterschiedlichen Zeitpunkten ab, weil jeder den Eintrag zu einem anderen Zeitpunkt geholt hat. Bis zu eine TTL lang sehen verschiedene Nutzer nach einer Änderung verschiedene Antworten. Mehr ist „Propagation“ nicht.
Es zählt die alte TTL. Ein Resolver, der den Eintrag gestern mit einer TTL von 86400 gespeichert hat, behält ihn für den Rest dieser 24 Stunden, ganz gleich, was Sie heute einstellen.

Caches, die Sie nicht kontrollieren

Der rekursive Resolver ist nicht der einzige Cache. Betriebssysteme, Browser und Anwendungen führen eigene, und nicht alle halten sich genau an die TTL: Browser behalten Adressen für eine kurze, feste Zeit, und lang laufende Anwendungen (ältere Java-Laufzeitumgebungen sind das klassische Beispiel) speichern ein Ergebnis unter Umständen so lange, wie der Prozess lebt. Manche Resolver setzen zudem eine Unter- oder Obergrenze: Eine TTL von 5 Sekunden wird dann wie 30 oder 60 behandelt, und sehr lange TTLs werden bei etwa einem Tag gekappt. Außerdem dürfen Resolver abgelaufene Daten noch kurze Zeit ausliefern, wenn die autoritativen Server nicht erreichbar sind.

Eine TTL ist also ein deutlicher Hinweis, aber keine Garantie. Es wäre unredlich zu versprechen, eine Änderung sei nach genau N Sekunden „überall“ sichtbar.

Negative Caching: die TTL von „gibt es nicht“

Ein Resolver speichert auch die Antwort „diesen Namen gibt es nicht“ (NXDOMAIN) sowie „dieser Name hat keinen Eintrag dieses Typs“. Die Dauer ergibt sich aus dem SOA-Record der Zone: Es gilt der kleinere Wert aus der TTL des SOA-Records selbst und seinem letzten Feld (historisch „minimum“ genannt).

$ dig +noall +authority nosuch.example.com
example.com.  300  IN  SOA  ns1.dns.example. hostmaster.example.com. 2026092001 7200 3600 1209600 300

Das ist die übliche Erklärung für: „Ich habe den Eintrag angelegt, der autoritative Server liefert ihn, aber mein Resolver behauptet weiterhin, es gebe ihn nicht.“ Jemand (oft Sie selbst, weil Sie zu früh nachgesehen haben) hat den Namen abgefragt, bevor er existierte, und die negative Antwort liegt im Cache. Bei einer negativen TTL von 300 sind das fünf ärgerliche Minuten, bei 86400 ein verlorener Tag. Halten Sie den Wert moderat. Werte zwischen 300 und 3600 sind vernünftig.

Welche TTL-Werte sinnvoll sind

Die eine richtige Zahl gibt es nicht. Es ist eine Abwägung zwischen Beweglichkeit und Ausfallsicherheit:

	Niedrige TTL (60–300)	Hohe TTL (3600–86400)
Änderungen wirken	schnell	langsam
Fehler	sind schnell behoben	bleiben stundenlang bestehen
Abfragelast auf den autoritativen Servern	höher	niedriger
Latenz der Namensauflösung für Nutzer	mehr Cache-Misses	meist aus dem Cache
Bei einem Ausfall Ihres DNS-Anbieters	Namen lösen binnen Minuten nicht mehr auf	Antworten im Cache tragen die Nutzer hindurch

Die letzte Zeile wird oft vergessen. Eine lange TTL ist eine kostenlose Versicherung gegen einen kurzen DNS-Ausfall.

Sinnvolle Ausgangswerte:

Eintrag	Typische TTL	Begründung
`A`/`AAAA` einer stabilen Website	3600	Änderungen sind selten und geplant
`A`/`AAAA` für Failover oder hinter einem Load Balancer	60–300	muss schnell wechseln können, oft vom Anbieter vorgegeben
`CNAME` auf einen SaaS-Dienst oder ein CDN	3600	für die endgültige Adresse gilt die TTL des Ziels
`MX`	3600–86400	Mailserver ändern sich selten, Absender versuchen es ohnehin erneut
`TXT` (SPF, DKIM, DMARC)	3600	vor geplanten Änderungen senken
`NS` und `SOA`	86400	stabil, die TTL der Delegation in der übergeordneten Zone liegt nicht in Ihrer Hand
`CAA`	3600–86400	CAs beachten die TTL bei erneuter Prüfung

Bietet Ihr Anbieter „Auto“ an, bedeutet das meist 300 Sekunden. Für die meisten Websites ist das in Ordnung.

Eine Änderung mit TTLs planen

Der Ablauf, wenn Sie eine Website, einen Mailserver oder irgendetwas anderes hinter einem DNS-Namen umziehen:

Aktuelle TTL ermitteln, und zwar beim autoritativen Server. Nennen wir sie T.
Auf 300 senken (nicht tiefer, manche Resolver ignorieren sehr kleine Werte) und mindestens T abwarten. Erst wenn T verstrichen ist, können Sie sicher sein, dass jeder Cache die Version mit 300 Sekunden hält.
Die Änderung durchführen.
Prüfen, und zwar beim autoritativen Server und bei einigen öffentlichen Resolvern.
Das alte Ziel weiterlaufen lassen, mindestens für die Dauer der neuen TTL, realistisch einige Stunden, wegen der Caches, die sich nicht an die Regeln halten.
Die TTL wieder anheben, sobald feststeht, dass Sie nicht zurückrollen.

Die TTL senken und den Eintrag in ein und demselben Schritt ändern: Das ist der klassische Fehler. Die Resolver, auf die es ankommt, halten den alten Eintrag mit der alten TTL und bekommen Ihre neue TTL gar nicht zu sehen, bevor die alte abgelaufen ist.

Beachten Sie, dass bei einem Nameserver-Wechsel eine zweite TTL im Spiel ist: die der Delegation in der übergeordneten Zone. Sie beträgt üblicherweise zwei Tage und lässt sich von Ihnen nicht ändern. Was ein Nameserver ist und was die Delegation bedeutet, steht im Glossar.

TTL und CNAME-Ketten

Ist ein Name ein CNAME, speichert der Resolver jedes Glied der Kette einzeln, jedes mit seiner eigenen TTL:

www.example.com.        3600  IN  CNAME  site.cdn.example.
site.cdn.example.         60  IN  A      203.0.113.20

Das CDN kann seinen A-Record binnen einer Minute umziehen. Wollen Sie aber www auf ein anderes CDN zeigen lassen, gelten Ihre eigenen 3600 Sekunden. Die tatsächliche Verzögerung einer Änderung ist die TTL des Eintrags, den Sie ändern, nicht die kleinste in der Kette.

Kann ich den DNS-Cache leeren?

Ihren eigenen: ja.

# macOS
$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
> ipconfig /flushdns
# Linux mit systemd-resolved
$ resolvectl flush-caches

Einige öffentliche Resolver bieten ein Webformular an, mit dem sich ein Name aus ihrem Cache entfernen lässt. Das hilft nach einem Fehler. An die Resolver aller anderen kommen Sie nicht heran. Ein globales Leeren gibt es nicht, und wer verspricht, die „Propagation zu erzwingen“, verkauft einen Knopf, der nichts bewirkt.

Häufige Fehler

Die TTL im selben Moment wie die Änderung senken oder fünf Minuten davor.
Alles dauerhaft auf 60 Sekunden lassen, „um flexibel zu bleiben“, und dann zusammen mit dem DNS-Anbieter ausfallen.
Eine TTL von einem Tag auf einem Eintrag, der Teil eines Failover-Plans ist.
Den Wert für das Negative Caching vergessen und einen Namen abfragen, bevor er angelegt ist.
Eine Abfrage vom eigenen Laptop für den Beweis dessen halten, was die Nutzer sehen.
Glauben, die Prozentzahl eines „Propagation-Checkers“ beschreibe das ganze Internet. Sie beschreibt die Standorte, die dieses Werkzeug abgefragt hat.

Mit OrbitProbe prüfen

Die DNS-Abfrage von OrbitProbe zeigt neben jedem Eintrag die TTL, so wie öffentliche Resolver sie in diesem Moment sehen. Vor einem Umzug finden Sie damit die TTLs, die Sie senken müssen. Nach der Änderung führen Sie die Abfrage erneut aus, um den neuen Wert zu bestätigen und die verbleibende TTL zu beobachten. Welche Einträge es überhaupt gibt, zeigt der Überblick DNS-Einträge erklärt. Gehört die Änderung zur Reparatur der E-Mail-Zustellung, hilft die DNS-Checkliste für E-Mails, die im Spam landen.