Time to Live (TTL) im DNS verständlich erklärt: Caching-Steuerung
Die Time to Live (TTL) ist einer der wichtigsten Steuerparameter im Domain Name System (DNS). Sie gibt in Sekunden an, wie lange ein DNS-Resolver (wie der Internet-Provider, Google DNS oder Cloudflare) die Antwort auf eine DNS-Abfrage in seinem lokalen Cache zwischenspeichern darf, bevor er den autoritativen Nameserver erneut kontaktieren muss. Die TTL regelt somit das Gleichgewicht zwischen schneller Update-Fähigkeit und Server-Entlastung.
Die TTL wird für jeden Record einzeln festgelegt und ist eng mit der DNS-Propagation verknüpft: Sie bestimmt, wie lange eine alte Antwort weltweit in Caches überlebt. Wer die DNS-Hierarchie versteht, erkennt schnell, warum eine Änderung am autoritativen Server nicht sofort überall ankommt.
Das Zusammenspiel von Caching und Abfragebelastung
Jede DNS-Abfrage benötigt Zeit (Latenz) und belastet die Nameserver. Caching löst dieses Problem: Fragt ein Benutzer die IP-Adresse von example.com ab, speichert sein Internet-Provider das Ergebnis. Ruft ein zweiter Benutzer desselben Providers kurz darauf dieselbe Website auf, liefert der Provider die IP direkt aus dem Cache aus – ohne den Nameserver der Website zu kontaktieren.
Die TTL bestimmt die Lebensdauer dieses Cache-Eintrags:
- Hohe TTL (z. B. 86400 Sekunden / 24 Stunden):
- Vorteil: Minimale Nameserver-Belastung und maximale Geschwindigkeit bei wiederkehrenden Zugriffen, da der Provider-Resolver die Antwort sofort parat hat.
- Nachteil: Ändern Sie eine Einstellung (z. B. die IP-Adresse im A-Record), dauert es bis zu 24 Stunden, bis diese Änderung weltweit bei allen Nutzern ankommt (DNS-Ausbreitungsverzögerung).
- Niedrige TTL (z. B. 300 Sekunden / 5 Minuten):
- Vorteil: Änderungen werden extrem schnell aktiv. Dies ist ideal für dynamische IP-Adressen, Load-Balancing-Verfahren oder Failover-Systeme.
- Nachteil: Höhere Latenzzeiten beim ersten Aufruf und massive Belastung der Nameserver, da der Cache alle 5 Minuten verfällt.
Empfohlene TTL-Werte nach Record-Typ
Nicht jeder Eintrag braucht dieselbe Cache-Dauer. Die folgende Tabelle nennt bewährte Richtwerte:
| Record-Typ | Empfohlene TTL | Begründung |
|---|---|---|
| A / AAAA (stabil) | 3600–86400 s | Ändert sich selten |
| A vor Migration | 300 s | schnelle Umschaltung nötig |
| MX | 3600–86400 s | Mailrouting bleibt stabil |
| TXT (SPF/DKIM) | 3600 s | gelegentliche Anpassungen |
| Failover/Load-Balancing | 30–300 s | schnelle Reaktion erforderlich |
Als Faustregel gilt: stabile Einträge hoch (1–24 Stunden), nur dynamische oder bald zu ändernde Einträge niedrig setzen.
Best Practice: TTL-Anpassung bei Server-Migrationen
Ein klassischer Administrations-Fehler ist der Server-Umzug (IP-Wechsel) bei hoher TTL, was zu stundenlangen Ausfallzeiten führt. Mit vorausschauender Planung lässt sich dies vermeiden:
1. TTL senken (24-48h vorher) 2. IP ändern (Go-Live) 3. TTL anheben (danach)
┌───────────────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Alt: 86400s (24h) │ ──► Alt-IP -> Neu-IP │ ──► Neu: 86400s (24h) │
│ Neu: 300s (5 Min) │ │ (Sofort aktiv bei │ │ (Entlastet den │
│ (Warten, bis Cache abläuft) │ │ allen Clients) │ │ Nameserver wieder) │
└───────────────────────────────┘ └──────────────────────┘ └──────────────────────┘
- Vorbereitung (24 bis 48 Stunden vor dem Umzug): Senken Sie die TTL des betroffenen Records (z. B. des A-Records) von 86400 auf 300 Sekunden. Warten Sie mindestens 24 Stunden, damit alle alten Cache-Einträge weltweit verfallen.
- Der Umzug: Ändern Sie die IP-Adresse auf den neuen Server. Da die TTL auf 5 Minuten steht, fragen Resolver die IP nun alle 5 Minuten neu ab. Innerhalb von wenigen Minuten greifen fast alle Besucher weltweit auf den neuen Server zu.
- Nachbereitung: Sobald der Umzug erfolgreich abgeschlossen ist und das System stabil läuft, heben Sie die TTL wieder auf 86400 Sekunden an, um die Nameserver zu entlasten und die Performance zu maximieren.
Vorher/Nachher: Server-Umzug mit und ohne TTL-Planung
Der Unterschied zwischen geplanter und ungeplanter TTL-Anpassung ist drastisch:
| Szenario | TTL beim Umzug | Folge für Besucher |
|---|---|---|
| Ohne Planung | 86400 s (24 h) | Teil der Nutzer landet bis zu 24 h auf dem alten Server |
| Mit Planung | vorab auf 300 s gesenkt | Umschaltung in wenigen Minuten weltweit |
Läuft eine Umstellung trotz gesenkter TTL nicht durch, hilft das systematische DNS-Troubleshooting, die Ursache (z. B. ein hartnäckiger Zwischen-Cache) einzugrenzen.
[!TIP] Die TTL steuert, wie flexibel Sie auf Infrastruktur-Probleme reagieren können. Prüfen Sie die aktuellen Cache-Zeiten (TTL) Ihrer Domain mit dem DNS Check auf balou.tools.
Häufig gestellte Fragen (FAQ)
Welcher Standardwert (TTL) wird für normale Websites empfohlen?
Für statische Einstellungen wie MX-Records, TXT-Records oder A-Records stabiler Server hat sich ein Wert von 3600 Sekunden (1 Stunde) oder 86400 Sekunden (24 Stunden) in der Praxis bewährt.
Kann man die DNS-Ausbreitung (Propagation) durch eine niedrige TTL beschleunigen?
Ja, aber nur, wenn die TTL bereits *vor* der Änderung gesenkt wurde. Eine nachträgliche Senkung der TTL verkürzt die Wartezeit nicht, da die alten DNS-Resolver den alten Wert noch gemäss der ursprünglichen TTL im Cache halten.
Was bedeutet eine TTL von 0 Sekunden?
Eine TTL von 0 weist Resolver an, die Antwort gar nicht zwischenzuspeichern und bei jeder Anfrage erneut den autoritativen Nameserver zu kontaktieren. Das wird selten und nur für hochdynamische Failover-Szenarien genutzt, da es die Nameserver stark belastet und die Latenz erhöht. Viele Resolver erzwingen ohnehin eine Mindest-Cachezeit.
Wo sehe ich die verbleibende TTL eines DNS-Eintrags?
Mit dem Befehl `dig example.com` zeigt die Antwortzeile die aktuell verbleibende Cache-Dauer in Sekunden an. Bei einem wiederholten Aufruf zählt dieser Wert herunter – erreicht er null, fragt der Resolver den autoritativen Server neu ab. So lässt sich prüfen, ob eine Änderung bereits propagiert ist.