DNS-TTL verstehen: Warum Änderungen Zeit brauchen

Jeder DNS-Record trägt eine TTL – Time to Live –, angegeben in Sekunden. Sie ist eine Anweisung des autoritativen Nameservers der Domain an jeden Resolver, der den Record abruft: „Sie dürfen diese Antwort so lange wiederverwenden, bevor Sie erneut fragen.“ Eine TTL von 300 Sekunden bedeutet, dass ein Resolver, der eine Domain gerade nachgeschlagen hat, fünf Minuten lang nicht erneut fragt, selbst wenn sich der Record in der Zwischenzeit ändert.

Der Zielkonflikt, den die TTL austariert

Eine längere TTL bedeutet weniger DNS-Abfragen, schnellere durchschnittliche Lookups (weil mehr Anfragen aus dem Cache bedient werden) und weniger Last auf den autoritativen Nameservern. Eine kürzere TTL bedeutet, dass sich eine Änderung am Record schneller verbreitet – auf Kosten häufigerer Abfragen. Es gibt keinen universell richtigen Wert – er hängt davon ab, wie oft sich der Record voraussichtlich ändert und wie tolerant die Situation gegenüber veralteten Antworten ist.

Was bei einer Änderung tatsächlich passiert

Das Aktualisieren eines DNS-Records schiebt die Änderung nicht an jeden Resolver im Internet. Es ändert lediglich, was der autoritative Nameserver beim nächsten Mal antwortet, wenn er gefragt wird. Jeder Resolver, der die alte Antwort bereits gecacht hat, liefert sie weiter aus, bis die TTL seiner gecachten Kopie abläuft – weshalb dieselbe Domain kurzzeitig auf unterschiedliche Adressen aufgelöst werden kann, je nachdem, welcher Resolver und welcher Cache antwortet.

• Ein üblicher praktischer Schritt vor einer geplanten Migration ist, die TTL ein bis zwei Tage vorher zu senken, damit sich der eigentliche Cutover schneller verbreitet.
• Nach der Migration wird die TTL in der Regel wieder auf ihren normalen Wert angehoben.
• Ein Record ohne jüngste Änderungen und mit langer TTL kann nach einer Änderung dennoch das gesamte TTL-Fenster brauchen, bis er weltweit vollständig aus den Caches verschwunden ist.

Eine TTL in der Praxis wählen

Auch negative Antworten werden gecacht, was leicht übersehen wird. Existiert eine Domain nicht, wird die NXDOMAIN-Antwort selbst gecacht, geregelt durch einen eigenen Wert (die minimale TTL des SOA-Records, nicht die TTL eines Records, den es von vornherein nie gab). Eine neu registrierte Domain kann danach mitunter kurzzeitig nicht aufgelöst werden, einfach weil ein Resolver ihr NXDOMAIN von vor Abschluss der Registrierung bereits gecacht hatte.

Die TTL ist eine Bitte, keine Garantie

Man sollte wissen, dass eine TTL eine Empfehlung ist, die keine äußere Instanz durchsetzt. Ein Resolver darf eine Antwort technisch länger als die angegebene TTL cachen (manche tun das unter hoher Last, um das Abfragevolumen zu senken) oder sie früher verwerfen (ein Resolver mit knappem Speicher kann Cache-Einträge vorzeitig löschen). In der überwältigenden Mehrheit der Fälle halten gut betriebene öffentliche und ISP-Resolver TTLs eng und vorhersehbar ein – doch deshalb ist eine auf der TTL beruhende Propagierungsschätzung eine belastbare Faustregel und keine feste, vertragliche Garantie. Wenn eine Änderung nach Ablauf des alten TTL-Fensters noch immer nicht spürbar sichtbar ist, ist ein ungewöhnlich aggressiver zwischengeschalteter Cache eine der selteneren, aber realen Erklärungen, die man im Hinterkopf behalten sollte.

Wenn Sie prüfen, ob eine DNS-Änderung live gegangen ist, sagt ein einzelner Lookup nur, was ein Resolver gerade gecacht hat. Den Lookup im Abstand einiger Minuten zu wiederholen – oder eine wiederkehrende Prüfung zu planen – ist ein weit zuverlässigerer Weg, zu bestätigen, dass sich eine Änderung tatsächlich verbreitet hat, als einmal eine veraltete gecachte Antwort zu erwischen und sie für endgültig zu halten.