DNSRatgeber
TTL bei DNS: wie lange Resolver einen Eintrag zwischenspeichern
Die TTL (Time to Live) ist eine Zahl in Sekunden, die an jedem DNS-Eintrag hängt. Sie sagt Resolvern, wie lange sie den Eintrag zwischenspeichern dürfen, bevor sie neu nachfragen. Eine kurze TTL macht Änderungen schnell wirksam, eine lange spart Abfragen.

Jeder DNS-Eintrag trägt neben Name, Typ und Wert eine Zahl: die TTL, ausgeschrieben Time to Live. Sie gibt in Sekunden an, wie lange ein Resolver den Eintrag in seinem Zwischenspeicher behalten darf, bevor er die zuständigen Nameserver wieder fragen muss [1, 2]. Von diesem Wert hängt ab, wie schnell eine Änderung bei deinen Besuchern ankommt und wie viele Anfragen deine Nameserver beantworten müssen. Wie der ganze Ablauf nach einer Änderung aussieht, beschreibt die Seite DNS-Änderung: wie lange dauert es, bis sie überall gilt?. Hier geht es um den Wert selbst: was er bedeutet, welche Grenzen gelten und wie du ihn wählst.
Was die TTL genau bedeutet
Fragt dein Rechner nach www.beispiel.de, landet die Frage meist bei einem Resolver deines Internetanbieters oder eines DNS-Dienstes. Dieser holt die Antwort beim zuständigen Nameserver und merkt sie sich. Ab diesem Moment zählt die TTL rückwärts [3]. Fragt in der Zwischenzeit ein anderer Nutzer dasselbe, bekommt er die gespeicherte Antwort, und zwar mit der verbleibenden Restzeit als TTL. Ist die Zeit abgelaufen, gilt der Eintrag als veraltet und wird nicht mehr verwendet [3]. Die nächste Frage geht wieder an den Nameserver.

Daraus folgt: Änderst du einen Eintrag, sehen manche Nutzer den neuen Wert sofort, andere erst, wenn ihr Resolver den alten Wert vergessen hat. Im ungünstigsten Fall dauert das so lange, wie die TTL des alten Eintrags war.
Grenzen des Werts
Die TTL ist eine 32-Bit-Zahl in Sekunden. RFC 2181 legte 1997 fest, dass sie vorzeichenlos ist und zwischen 0 und 2.147.483.647 liegt, also höchstens 2 hoch 31 minus 1 Sekunden [4]. Das wären rund 68 Jahre. RFC 8767 hat die Definition 2020 ergänzt: Werte sollen in der Größenordnung von Tagen bis Wochen begrenzt werden, empfohlen ist eine Obergrenze von 604.800 Sekunden, also sieben Tagen. Das entspricht der Praxis großer Resolver [2].
Eine TTL von 0 bedeutet, dass der Eintrag nur für die laufende Anfrage gilt und gar nicht gespeichert werden soll [1]. Das ist für sehr schnell wechselnde Daten gedacht und in der Praxis selten sinnvoll, weil dann jede Anfrage bis zum Nameserver durchgereicht wird.
| Sekunden | entspricht | typischer Einsatz |
|---|---|---|
| 60 bis 300 | 1 bis 5 Minuten | kurz vor und während einer Umstellung |
| 3600 | 1 Stunde | verbreiteter Standardwert, etwa bei Microsoft 365 |
| 86400 | 1 Tag | Einträge, die sich selten ändern |
| 604800 | 7 Tage | empfohlene Obergrenze nach RFC 8767 |
Welche Werte Anbieter vorgeben
Viele DNS-Anbieter begrenzen die TTL in ihrer Oberfläche. Bei Cloudflare liegt die Spanne für Einträge ohne Proxy zwischen 60 Sekunden (30 Sekunden im Enterprise-Tarif) und einem Tag. Die Einstellung "Auto" entspricht 300 Sekunden. Einträge, die über den Cloudflare-Proxy laufen, haben immer 300 Sekunden, und der Wert lässt sich nicht ändern [5]. Cloudflare weist darauf hin, dass es trotzdem länger als fünf Minuten dauern kann, bis du eine Änderung siehst, weil dein lokaler Zwischenspeicher eigene Zeiten hat [5].
Mailanbieter nennen eigene Werte. Microsoft empfiehlt für die Einträge von Microsoft 365 eine TTL von 3600 Sekunden und schreibt, dass Exchange Online nur TTL-Werte unter sechs Stunden (21.600 Sekunden) unterstützt [6]. Wer seinen MX-Eintrag einrichtet, übernimmt am besten den Wert des Mailanbieters.
Eine ältere Empfehlung findet sich in RFC 1912 von 1996. Dort heißt es, eine TTL von einem Tag sei für Zonen mit stabilen Daten zu kurz, empfohlen seien drei Tage oder mehr. Für oft abgefragte, selten geänderte Einträge wie die MX-, A- und PTR-Einträge des Mailservers und die NS-Einträge der Zone nennt das Dokument sogar ein bis zwei Wochen [7]. Heute liegen solche Werte über der Obergrenze von sieben Tagen, die RFC 8767 empfiehlt [2]. Cloudflare erlaubt bei Einträgen ohne Proxy höchstens einen Tag [5].
Cloudflare beschreibt den Zielkonflikt knapp: Lange TTLs beschleunigen DNS-Abfragen, weil öfter eine gespeicherte Antwort vorliegt, verzögern aber jede Änderung [5]. Das gilt auch für Fehler. Hat sich in einen Eintrag mit einem Tag TTL ein Tippfehler eingeschlichen, bleibt die falsche Antwort bei manchen Resolvern bis zu 24 Stunden im Speicher, auch wenn du den Fehler nach fünf Minuten korrigierst. Google nennt für die MX-Einträge von Workspace den Standardwert des Registrars oder den Wert 1 [11]. Wer unsicher ist, kann sich an den 3600 Sekunden orientieren, die Microsoft für seine Einträge nennt [6].
Die TTL vor einer Änderung senken
Die TTL ist das wichtigste Werkzeug, um Umzüge ohne lange Übergangszeit zu planen. Der Ablauf funktioniert bei jedem Eintragstyp gleich:

- Mindestens eine volle alte TTL vor der Änderung den Wert senken, etwa von 86400 auf 300 Sekunden. Erst wenn die alte TTL einmal abgelaufen ist, haben alle Resolver den kurzen Wert übernommen.
- Die eigentliche Änderung machen, zum Beispiel den A-Eintrag auf die IP-Adresse des neuen Servers setzen.
- Prüfen, ob alles läuft. Mit der kurzen TTL lässt sich ein Fehler schnell zurücknehmen.
- Die TTL wieder auf einen längeren Wert setzen, sobald die neue Einstellung stabil ist.
Dieses Vorgehen hilft beim Wechsel des Webhostings, beim Umstellen des Mailanbieters und beim Einrichten eines CDN. Bei einem Nameserverwechsel greift es nur zum Teil: Die TTL der Einträge in deiner Zone kannst du senken, die TTL der Delegation in der Zone der Endung legt dagegen die Registry fest. Gehört die Änderung zu einem Umbau der Website, kommen SEO-Fragen dazu, siehe Website-Relaunch ohne Rankingverlust.
Negative Antworten haben auch eine TTL
Resolver speichern auch die Antwort "gibt es nicht". Fragst du nach einer Subdomain, die noch nicht existiert, merkt sich der Resolver dieses Ergebnis. Legst du die Subdomain kurz danach an, sieht er sie erst, wenn die gespeicherte negative Antwort abgelaufen ist.

Wie lange das dauert, steht im SOA-Eintrag der Zone. Nach RFC 2308 gilt für negative Antworten der kleinere von zwei Werten: das letzte Feld des SOA-Eintrags, MINIMUM genannt, oder die TTL des SOA-Eintrags selbst [8]. Das Feld MINIMUM hatte früher noch andere Bedeutungen. RFC 2308 hat es 1998 auf genau diesen Zweck festgelegt und für die Standard-TTL einer Zonendatei die Anweisung $TTL eingeführt [8].
Für .de-Domains gibt die DENIC bei der Prüfung der Nameserver eine Spanne vor: Die TTL für negative Antworten soll zwischen 180 und 86400 Sekunden liegen. Abweichungen führen nur zu einer Warnung [9].
Wenn Resolver abgelaufene Einträge weiter nutzen
Seit RFC 8767 dürfen Resolver einen abgelaufenen Eintrag weiter ausliefern, wenn sie die zuständigen Nameserver nicht erreichen. Das soll Ausfälle abfedern, etwa bei einem Angriff auf den Nameserver [2]. Ein so ausgelieferter Eintrag bekommt eine TTL größer als 0, empfohlen sind 30 Sekunden [2]. Laut RFC 8767 bieten mehrere verbreitete Resolver diese Möglichkeit an, auch macOS kann veraltete Daten nutzen [2].
Für dich heißt das: Fällt dein Nameserver aus, funktioniert die Domain bei manchen Nutzern noch eine Weile weiter. Verlassen kannst du dich darauf aber nicht, weil jeder Resolver das anders handhabt.
TTL und DNSSEC
Bei signierten Zonen gibt es eine zweite Zeitangabe: die Gültigkeitsdauer der Signatur. Jede Signatur hat einen Beginn und ein Ende. RFC 4033 trennt beides ausdrücklich. Die TTL ändert sich durch DNSSEC nicht, aber eine lange TTL kann eine abgelaufene Signatur nicht verlängern. Resolver dürfen die verbleibende Gültigkeit der Signatur als Obergrenze für die Speicherdauer nehmen [10].
TTL selbst prüfen
Die aktuelle TTL eines Eintrags siehst du in der Verwaltungsoberfläche deines DNS-Anbieters und in der Antwort jeder DNS-Abfrage. Mit dem DNS-Check kannst du die Einträge einer Domain abfragen. Fragst du über einen Resolver ab, der den Eintrag schon gespeichert hat, siehst du die Restzeit, die bei jeder Abfrage kleiner wird. Die volle TTL zeigt nur eine direkte Abfrage beim zuständigen Nameserver. Wie ein Eintrag überhaupt aufgebaut ist, erklärt DNS-Einträge im Überblick.
- Gesetz RFC 1035: Domain Names, Implementation and Specification, Abschnitt 3.2.1. IETF. Stand November 1987. abgerufen am 29.10.2026
- Gesetz RFC 8767: Serving Stale Data to Improve DNS Resiliency. IETF. Stand März 2020. abgerufen am 29.10.2026
- Gesetz RFC 1035: Domain Names, Implementation and Specification, Abschnitt 6.1.3. IETF. Stand November 1987. abgerufen am 29.10.2026
- Gesetz RFC 2181: Clarifications to the DNS Specification, Abschnitt 8. IETF. Stand Juli 1997. abgerufen am 29.10.2026
- Organisation Time to Live (TTL). Cloudflare. Stand 16.04.2026. abgerufen am 29.10.2026
- Organisation Verbinden Ihrer Domäne durch Hinzufügen von DNS-Einträgen. Microsoft. Stand 23.04.2026. abgerufen am 29.10.2026
- Gesetz RFC 1912: Common DNS Operational and Configuration Errors, Abschnitt 2.2. IETF. Stand Februar 1996. abgerufen am 29.10.2026
- Gesetz RFC 2308: Negative Caching of DNS Queries (DNS NCACHE), Abschnitte 4 und 5. IETF. Stand März 1998. abgerufen am 29.10.2026
- Organisation DENIC-23, Abschnitt 2: Nameserver Predelegation Check. DENIC eG. Stand ohne Datum. abgerufen am 29.10.2026
- Gesetz RFC 4033: DNS Security Introduction and Requirements, Abschnitt 8.1. IETF. Stand März 2005. abgerufen am 29.10.2026
- Organisation MX-Einträge für Google Workspace einrichten. Google. Stand ohne Datum. abgerufen am 29.10.2026
Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.
Weitere Artikel
DNSDNS-ÄnderungWarum eine DNS-Änderung nicht sofort überall ankommt, welche Rolle die TTL spielt und wie du einen Umzug so planst, dass die …
DNSNameserver ändern ohne AusfallWer die Nameserver einer Domain ändert, verlegt ihre ganze DNS-Zone.
DNSDNSSECDNSSEC versieht DNS-Antworten mit Signaturen.
Häufige Fragen zu Domains, DNS und SSLKurze Antworten auf häufige Fragen zu Domain, Umzug, DNS-Änderungen, SSL-Laufzeit, Wildcard-Zertifikat, SPF und zu …