Die Rolle der DNS-TTL-Einstellungen

Jede DNS-Antwort trägt eine Zahl mit sich: die Time to Live, kurz TTL. Sie wird leicht übersehen, weil DNS-Panels einen Standardwert eintragen und die meisten ihn nie anfassen. Dabei entscheidet genau dieser eine Wert, wie schnell eine Änderung an Website, E-Mail oder API bei den Nutzern ankommt, wie viel Last Ihre Nameserver tragen und wie gut Ihre Domain den Ausfall eines Anbieters übersteht. Wer TTL versteht, erlebt Migrationen, die in fünf Minuten erledigt sind – statt solcher, die sich einen ganzen Tag hinziehen.

Dieser Leitfaden erklärt, was die TTL tatsächlich bewirkt, wie Sie sinnvolle Werte wählen, wie Sie eine Migration darauf abstimmen und warum reale Caches sich nicht immer an die Zahl halten, die Sie festlegen.

Was TTL im DNS bedeutet

Die TTL ist ein Feld in jedem Resource Record und wird in Sekunden angegeben. Holt ein rekursiver Resolver – etwa der Ihres Internetanbieters oder ein öffentlicher wie 1.1.1.1 oder 8.8.8.8 – einen Record von einem autoritativen Nameserver, speichert er die Antwort und zählt die TTL herunter. Bis sie null erreicht, beantwortet der Resolver Anfragen aus seinem Cache, ohne den autoritativen Server erneut zu fragen. Läuft sie ab, löst die nächste Anfrage einen frischen Lookup aus.

Den Countdown sehen Sie mit dig. Stellen Sie dieselbe Anfrage zweimal an einen Resolver, ist die TTL im Answer-Bereich beim zweiten Mal niedriger:

dig @8.8.8.8 example.com A +noall +answer
example.com.    2873    IN    A    93.184.215.14

Den ursprünglichen Wert, den der Zoneninhaber gesetzt hat, erfahren Sie, indem Sie direkt einen autoritativen Nameserver fragen:

dig NS example.com +short
dig @ns1.example-dns.net example.com A +noall +answer

Die viel zitierte „DNS-Propagation“ ist in Wahrheit genau das: Tausende unabhängiger Caches, die die alte Antwort jeweils nach ihrem eigenen Zeitplan verwerfen. Nichts wird aktiv verteilt; die Caches vergessen einfach.

Vor- und Nachteile kurzer und langer TTLs

Keine TTL passt für jeden Record. Jede Wahl ist ein Kompromiss zwischen Flexibilität einerseits sowie Effizienz und Ausfallsicherheit andererseits.

Eine lange TTL wirkt zudem als Sicherheitsnetz. Fällt Ihr autoritativer DNS-Anbieter aus, antworten Resolver, die Ihre Records vor einer Stunde gecacht haben, für den Rest dieser Stunde weiter. Bei einer TTL von 60 Sekunden spüren Nutzer einen Ausfall fast sofort. Kurze TTLs gibt es auch nicht gratis: Jeder Cache-Miss kostet einen zusätzlichen Roundtrip zu den autoritativen Servern.

Werte für jeden Record-Typ wählen

A, AAAA und CNAME

Für eine Website auf einem stabilen Server ist eine Stunde ein sinnvoller Ausgangswert. Nutzen Sie ein CDN oder einen gemanagten Load Balancer, folgen Sie den Empfehlungen des Anbieters; viele setzen auf ihren eigenen Records kurze TTLs, um Traffic zu steuern, während Ihr CNAME dorthin länger gültig bleiben kann.

MX und mailbezogene TXT-Records

Das Mail-Routing ändert sich selten, und Absender versuchen bei fehlgeschlagener Zustellung tagelang erneut zuzustellen – einige Stunden bis ein Tag sind daher in Ordnung. Senken Sie den Wert rechtzeitig, wenn Sie zu einem neuen E-Mail-Anbieter wechseln.

NS-Records

Die für die Delegation entscheidenden NS-Records liegen in der Elternzone und werden von der Registry verwaltet, oft mit einer TTL von ein oder zwei Tagen. Deshalb dauert ein Nameserver-Wechsel beim Registrar länger als die Änderung eines A-Records. Auf welche Nameserver eine Domain aktuell delegiert ist, prüfen Sie mit dem WHOIS-Lookup von TLDix.

SOA

Der SOA-Record enthält Timer für sekundäre Server sowie den unten beschriebenen Wert für negatives Caching. Seine eigene TTL liegt meist bei einer Stunde oder mehr.

TTL vor einer Migration senken

Die nützlichste Praxistechnik rund um die TTL ist, sie vor einer geplanten Änderung zu verkürzen. Das entscheidende Detail, das oft übersehen wird, ist das Timing: Resolver erfahren von Ihrer neuen, niedrigeren TTL erst, wenn ihre gecachte Kopie mit der alten TTL abgelaufen ist.

1. Aktuelle TTL prüfen – direkt auf dem autoritativen Server. Angenommen, sie beträgt 86400 Sekunden.
2. TTL senken auf 300 Sekunden, und zwar mindestens 24 Stunden – eine volle alte TTL – vor der Migration. Etwas länger zu warten ist sicherer.
3. Änderung durchführen, zum Beispiel den A-Record auf den neuen Server zeigen lassen. Die meisten Caches aktualisieren sich nun innerhalb von fünf Minuten.
4. Alten Server weiterlaufen lassen, denn einige Clients hinken hinterher.
5. TTL wieder anheben auf den Normalwert, sobald Traffic und Logs bestätigen, dass der Umzug abgeschlossen ist.

; 24+ hours before
www.example.com.   300    IN  A  203.0.113.10
; migration moment
www.example.com.   300    IN  A  198.51.100.20
; after verification
www.example.com.   3600   IN  A  198.51.100.20

Überspringen Sie Schritt 2 und ändern den Record, während die TTL noch einen Tag beträgt, erreichen manche Nutzer bis zu einen Tag lang den alten Server.

Negatives Caching und das SOA-Minimum

Resolver speichern auch das Fehlen eines Records. Existiert ein Name nicht (NXDOMAIN) oder existiert er ohne den angefragten Typ (NODATA), darf der Resolver laut RFC 2308 diese negative Antwort cachen. Ihre Lebensdauer ist der kleinere Wert aus der TTL des SOA-Records und dem letzten Feld im SOA, historisch „minimum“ genannt.

dig example.com SOA +noall +answer
example.com. 3600 IN SOA ns1.example-dns.net. hostmaster.example.com. 2026100701 7200 3600 1209600 3600

Die abschließende 3600 bedeutet hier, dass ein fehlgeschlagener Lookup eine Stunde lang gespeichert werden kann. Das wird zum Problem, wenn eine neue Subdomain abgefragt wird, bevor sie angelegt ist: Ein Monitoring-Check, ein Zertifikatsvalidierungsversuch oder ein ungeduldiger Test cacht NXDOMAIN, und der neue Record scheint dann „nicht zu propagieren“. Legen Sie Records daher an, bevor irgendetwas sie abfragt, und halten Sie die negative TTL im SOA moderat, typischerweise bei 300 bis 3600 Sekunden.

Wenn Resolver Ihre TTL begrenzen oder ignorieren

Die veröffentlichte TTL ist ein Höchstwert, keine Garantie. Mehrere Ebenen können sie verändern:

• Resolver-Grenzen. Software wie BIND und Unbound hat konfigurierbare maximale Cache-Zeiten, und Betreiber können Mindestwerte setzen, sodass sehr kurze TTLs angehoben werden. Das Standardmaximum von BIND liegt bei einer Woche, der negative Cache ist standardmäßig auf drei Stunden begrenzt.
• Serve-Stale. RFC 8767 erlaubt Resolvern, mit abgelaufenen Daten weiterzuantworten, wenn autoritative Server nicht erreichbar sind. Das erhöht die Ausfallsicherheit, kann aber die Lebensdauer alter Antworten verlängern.
• Betriebssysteme und Browser. Lokale Stub-Resolver und Browser führen eigene kurze Caches, unabhängig vom Resolver im Netz.
• Anwendungen. Lang laufende Prozesse lösen einen Namen eventuell nur einmal auf und verwenden die Adresse weiter; manche Laufzeitumgebungen haben eigene DNS-Cache-Einstellungen.

Fazit: Planen Sie einen langen Nachlauf ein. Nach jeder Änderung zieht der Großteil des Traffics innerhalb der TTL um, ein kleiner Rest bleibt länger hängen.

Praxisbeispiel: Umzug zu einem neuen Hoster

Angenommen, Ihr Onlineshop zieht am Samstagmorgen zu einem neuen Hoster um. Am Donnerstag prüfen Sie die TTL des A-Records für www und des Apex: beide stehen auf 14400 Sekunden. Sie senken beide auf 300 Sekunden und warten mindestens vier Stunden, besser bis Freitag. Am Samstag stellen Sie die Datenbank auf den neuen Server um, ändern die A-Records und beobachten die Zugriffslogs beider Server. Nach etwa einer Stunde kommen auf dem alten Server nur noch vereinzelte Anfragen an, meist von Bots und lang laufenden Clients. Lassen Sie ihn dennoch ein bis zwei Tage als Fallback aktiv, idealerweise mit einer Weiterleitung, und setzen Sie die TTL am Montag wieder auf eine Stunde.

Monitoring und gute Gewohnheiten

• Dokumentieren Sie die normale TTL jedes Records, damit vorübergehende Absenkungen nicht in Vergessenheit geraten.
• Vergleichen Sie nach Änderungen die autoritativen Antworten mit mehreren öffentlichen Resolvern.
• Vermeiden Sie TTLs unter 30 Sekunden, sofern Ihr Anbieter sie nicht ausdrücklich benötigt.
• Verbinden Sie DNS-Änderungen mit der Überwachung der Ablaufdaten von Domain, Zertifikaten und Hosting – eine abgelaufene Domain legt DNS unabhängig von jeder TTL lahm.

Hilfreich ist außerdem eine kurze Checkliste für jede geplante Änderung: alte TTL notieren, Absenkungszeitpunkt festhalten, Änderungsfenster mit dem Team abstimmen und einen Termin für das Zurücksetzen der TTL im Kalender eintragen. So bleibt nichts dem Zufall überlassen.

Eine Auffrischung zu den einzelnen Record-Typen bietet unser Leitfaden zu den Grundlagen von DNS-Records.