DNS-Glossar
Was ist TTL (Time to Live)?
DNS-TTL (Time to Live) ist eine DNS-Einstellung, die Resolvern angibt, wie viele Sekunden sie eine Antwort zwischenspeichern dürfen, bevor sie diese verwerfen. Sie wird mit jedem Ressourceneintrag gespeichert, sodass verschiedene Einträge in derselben Zone für unterschiedliche Zeiträume zwischengespeichert werden können.
Die wichtigsten ErkenntnisseDie wichtigsten Erkenntnisse werden mithilfe von KI generiert. Da automatisierte Zusammenfassungen gelegentlich Fehler enthalten oder wichtige Zusammenhänge auslassen können, sollten Sie für vollständige Informationen stets den vollständigen Blogbeitrag lesen.DNS TTL (Time to Live) is a record setting that controls how long resolvers cache DNS responses in seconds before discarding them, with each resource record carrying its own TTL value set by the authoritative zone administrator. TTL represents a fundamental trade-off between performance and agility: longer values reduce query load and latency for users at scale but delay change propagation, while shorter values enable faster updates but increase server load and reduce resilience during outages. Common operational challenges include insufficient planning for cached TTL during migrations, premature TTL reduction, and resolver-level TTL overrides that can cause unexpected behavior diverging from zone configuration.
So funktioniert die DNS-TTL
Jeder DNS-Ressourceneintrag enthält einen TTL-Wert in Sekunden, der vom Administrator der autoritativen Zone festgelegt wird. Resolver verwenden diesen Wert, um zu entscheiden, wie lange eine gespeicherte Antwort gültig bleibt.
- Autoritative Antwort: Ein rekursiver Resolver fragt den autoritativen Server ab, der den Eintrag zusammen mit seiner konfigurierten TTL zurückgibt, beispielsweise 3600 Sekunden.
- Cache-Speicherung: Der Resolver speichert den Eintrag und beginnt, die TTL vom ursprünglichen Wert herunterzuzählen.
- Cache-Treffer: Solange die TTL über Null liegt, beantwortet der Resolver passende Client-Anfragen aus seinem Cache. Die TTL in jeder Antwort gibt die verbleibenden Sekunden an, nicht den ursprünglichen Wert.
- Ablauf: Wenn die TTL den Wert Null erreicht, entfernt der Resolver den Eintrag aus dem Cache.
- Aktualisierung: Bei der nächsten passenden Anfrage fragt der Resolver erneut beim autoritativen Server nach, wodurch die volle TTL wiederhergestellt wird.
Caches auf verschiedenen Ebenen, wie z. B. im Betriebssystem, im Browser und in weiterleitenden Resolvern, wenden jeweils ihren eigenen Countdown an, sodass es länger als eine TTL dauern kann, bis eine Änderung überall sichtbar wird. Auch negative Antworten, wie z. B. nicht existierende Namen, werden zwischengespeichert, wobei ihre Lebensdauer durch den SOA-Eintrag gemäß RFC 2308 geregelt wird. Einige Resolver wenden Mindest- oder Höchstgrenzen an, die die veröffentlichte TTL außer Kraft setzen.
Häufige Probleme mit der DNS-TTL
Ein Eintrag wurde geändert, doch einige Clients greifen weiterhin auf die alte Adresse zu, bis die zwischengespeicherten Kopien ablaufen. Die Ursache ist in der Regel eine lange TTL, die zum Zeitpunkt der Änderung beibehalten wurde, und die Verzögerung kann so lange andauern wie die alte TTL.
Ein Administrator verkürzt die TTL am Tag einer Migration und erwartet eine sofortige Wirkung. Resolver, die den Eintrag mit dem alten Wert zwischengespeichert haben, behalten ihn jedoch noch bis zum Ablauf der alten TTL bei; daher muss die Verkürzung mindestens eine alte TTL-Periode vor der Änderung erfolgen.
Sehr niedrige Werte, wie beispielsweise wenige Sekunden, erhöhen das Abfragevolumen an autoritative Server und verlängern die Latenz bei der Suche. Während eines Ausfalls eines autoritativen Servers können Resolver nur auf wenige zwischengespeicherte Daten zurückgreifen, sodass die Störung die Nutzer schnell erreicht.
Einträge derselben Gruppe, wie beispielsweise mehrere A-Einträge für einen Namen, sollten dieselbe TTL haben. Abweichende Werte können dazu führen, dass sich Resolver unvorhersehbar verhalten und die Fehlerbehebung erschweren, da die Antworten voneinander abweichen, wenn die Caches zu unterschiedlichen Zeitpunkten ablaufen.
Einige cachingfähige Resolver wenden Mindest- oder Höchstgrenzen für die TTL an, sodass das beobachtete Verhalten von der Zonenkonfiguration abweicht. Techniker stellen fest, dass alte Daten über die veröffentlichte TTL hinaus bestehen bleiben oder dass ein Eintrag früher als erwartet aktualisiert wird, und müssen daher sowohl die Resolver-Einstellungen als auch die Zone überprüfen.
Verwandte Begriffe
Einrichtung von geregelten, auditfähigen IPAM-Workflow- und Genehmigungsmodellen für Unternehmensnetzwerke
Entdecken Sie IP-Management-Lösungen für geregelte, auditfähige IPAM-Workflows. Ermöglichen Sie bereichsbezogene Genehmigungen und lückenlose…
Content Hub Das OSI-Modell verstehen: Wo DNS und IP-Adressierung in die 7 Schichten passen
Machen Sie sich mit den sieben Schichten des OSI-Modells vertraut und erfahren Sie, wie DNS und IP-Adressierung in dieses Modell eingebunden sind. Lernen…
Skalierung von DNS und IPAM für IPv6- und Dual-Stack-Unternehmensnetzwerke
Skalieren Sie DNS und IPAM für Dual-Stack-Unternehmensnetzwerke. Erfahren Sie, wie Micetro Teams bei der Verwaltung von IPv6-Migrationen mit integrierten…
Einbindung von DNS, DHCP und IPAM in Ansible- und Git-basierte Infrastructure-as-Code-Pipelines
Durch die Einbindung von DNS, DHCP und IPAM in Ansible- und Git-basierte IaC-Pipelines mit Micetro werden Adress- und Eintragsänderungen zu versionierten,…
Podcast Podcast: Wie KI die Entwicklung von Unternehmenssoftware verändert
KI verändert die Netzwerkautomatisierung, doch eine sichere Implementierung erfordert solide Softwarepraktiken, Tests und Fachwissen, um Ausfälle zu…
Podcast Podcast: Why Open Platforms Matter in Network Operations
Open platforms and API-first architecture enable intelligent network operations, automation, and AI-driven workflows across hybrid enterprises.
Erhalten Sie mit LiveAssist Antworten aus den LiveNX-Daten, über die Sie bereits verfügen
Erfahren Sie, wie LiveAssist, das KI-gestützte Add-on für LiveNX, Ihre Netzwerkdaten in schnelle, gezielte Antworten umwandelt – mit einem Mehrwert, den…
Erstellung einer Kostenanalyse für den Ersatz bestehender appliancebasierter DDI-Lösungen durch eine Overlay-Verwaltungsschicht
Manuelle DDI-Arbeiten kosten die befragten Teams 1.040 Stunden pro Jahr. Hier erfahren Sie, wie Sie die Kosten für eine Verlängerung, den…