DNS-TTL: welche Werte für A, MX und TXT sinnvoll sind

Die TTL ist das einzige Feld in einem DNS-Eintrag, das keine Funktion hat, solange alles läuft. Sie wird erst interessant, wenn du etwas ändern willst. Dann ist es meist zu spät, sie anzupassen, und genau darum geht es hier.

Was die DNS-TTL steuert

Jeder Eintrag in einer Zone trägt eine TTL in Sekunden. Ein Resolver, der den Eintrag abfragt, merkt ihn sich so lange und zählt dabei herunter. Das siehst du mit zwei Abfragen kurz hintereinander:

dig @1.1.1.1 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

example.com.		3600	IN	A	192.0.2.10
example.com.		3571	IN	A	192.0.2.10

Die zweite Antwort kam 29 Sekunden später aus dem Cache. Erst wenn der Zähler bei 0 ist, fragt der Resolver beim autoritativen Nameserver nach. Deshalb bedeutet „TTL 3600“: Eine Änderung braucht bis zu eine Stunde, bis jeder Resolver sie sieht.

Wichtig: Die TTL wirkt auf den alten Wert. Was du beim Ändern als neue TTL einträgst, hilft erst bei der nächsten Änderung.

Empfohlene TTL-Werte nach Eintrag

Für einen VServer, an dem du nicht ständig etwas umbaust, sind 3600 Sekunden für fast alles ein vernünftiger Standard. Höhere Werte bringen kaum Vorteile, weil verbreitete Resolver-Software wie Unbound die Cache-Dauer standardmäßig auf einen Tag begrenzt (cache-max-ttl: 86400).

TTL-Strategie vor einem Umzug

So läuft eine geplante Änderung ohne lange Wartezeit:

1. Mindestens eine alte TTL vorher senkst du die TTL der betroffenen Einträge auf 300. Bei TTL 86400 also mindestens 24 Stunden vor dem Umzug.
2. Warten, bis die alte TTL abgelaufen ist. Jetzt cacht kein Resolver mehr länger als fünf Minuten.
3. Den Wert ändern, also die neue IP eintragen. TTL bleibt auf 300.
4. Prüfen, ob alles läuft. Falls nicht, zurückschalten, das dauert ebenfalls nur fünf Minuten.
5. Nach ein, zwei Tagen die TTL wieder auf 3600 anheben.

Der häufigste Fehler ist Schritt 2 auszulassen: TTL senken und sofort die IP ändern. Dann haben alle Resolver, die den alten Wert vor einer Minute gelesen haben, ihn noch 23 Stunden und 59 Minuten. Den kompletten Ablauf mit beiden Servern parallel beschreibt Server-Umzug ohne Downtime.

TTL im Zone-File und im SOA

Im Zone-File kannst du eine Standard-TTL für alle Einträge ohne eigene TTL setzen:

$ORIGIN example.com.
$TTL 3600
@      IN  SOA  ns1.example-dns.net. hostmaster.example.com. (
                2026101801 ; Serial
                7200       ; Refresh
                3600       ; Retry
                1209600    ; Expire
                3600 )     ; Minimum = Negativ-TTL
@      IN  A     192.0.2.10
@  300 IN  AAAA  2001:db8:10::1
www    IN  CNAME example.com.

Das letzte Feld im SOA ist seit RFC 2308 die Negativ-TTL: So lange merken sich Resolver, dass ein Name nicht existiert. Das betrifft dich, wenn du eine Subdomain zu früh im Browser aufrufst. Mehr dazu im Artikel über die Dauer der DNS-Propagation.

Bei gehosteten DNS-Panels wie dem Kundenbereich bei betadomain trägst du die TTL pro Eintrag ein und musst dich um $TTL und SOA nicht kümmern.

Was du mit der TTL nicht steuern kannst

Die Delegation. Welche Nameserver für deine Domain zuständig sind, steht in der Zone der Endung. Die TTL dort legt die Registry fest. Prüfen kannst du sie trotzdem:

dig @a.nic.de denic.de NS +norecurse +noall +authority

Bei .de kommt 86400 heraus. Ein Nameserver-Wechsel kann deshalb bis zu einen Tag dauern, egal was du in deiner eigenen Zone einträgst.

Resolver, die sich nicht an die Regeln halten. Manche setzen eine Mindest-TTL, andere eine Höchstgrenze. Ein paar Provider-Resolver halten Einträge auch länger als erlaubt. Darum lässt du den alten Server nach einer Umstellung lieber noch einen Tag weiterlaufen, auch wenn die Rechnung „fünf Minuten“ sagt.

Browser- und Betriebssystem-Caches. Die halten sich zwar meist an die TTL, aber eben nicht immer. Wenn nur dein eigener Rechner noch die alte IP sieht, ist das kein DNS-Problem auf der Serverseite.

Alle TTLs einer Domain auf einen Blick

Vor einem Umzug willst du wissen, welche Einträge welche TTL haben. Den autoritativen Server zu fragen ist dabei wichtig, weil ein Resolver dir nur die heruntergezählte Restzeit zeigt:

NS=$(dig NS example.com +short | head -n 1)
for t in A AAAA MX TXT; do dig @"$NS" example.com "$t" +noall +answer; done
dig @"$NS" www.example.com A +noall +answer

Die zweite Spalte ist die konfigurierte TTL. Der höchste Wert unter den Einträgen, die du ändern willst, bestimmt, wie früh du mit dem Senken anfangen musst.

Typische Denkfehler bei der TTL

„Niedrige TTL macht Änderungen schneller sichtbar.“ Nur, wenn sie schon vor der Änderung niedrig war.

„Ich setze einfach alles auf 60, dann bin ich flexibel.“ Geht, kostet aber bei jedem Cache-Miss eine Auflösung. Für ein Failover-Setup mit Health-Checks sinnvoll, für einen einzelnen VServer übertrieben.

„Die TTL bestimmt, wann der Eintrag aktiv wird.“ Nein. Der Eintrag ist auf dem autoritativen Server sofort aktiv. Die TTL regelt nur, wie lange alte Kopien woanders weiterleben. Wie du einen Eintrag überhaupt anlegst, zeigt A-Record setzen, und für Mail-Einträge gibt es MX-Record einrichten.

Nächster Schritt

Schau dir jetzt die TTLs deiner wichtigsten Einträge an, bevor der nächste Umzug ansteht. Bei betadomain stellst du sie im Kundenbereich pro Eintrag ein. Wenn du für ein Testsystem eine zweite Domain willst, lohnt der Blick in die Domainsuche. Eine .cloud-Domain kostet dort 25,99 € im Jahr, die vollständige Preisübersicht listet alle Endungen mit festem Verlängerungspreis.