Warum ultrakurze TTLs nicht (wie erwartet) funktionieren

Wir betreiben den Hostmaster-Dienst für einen großen Automobilhersteller und verwalten dabei etwa 50.000 DNS-Einträge. In dieser Umgebung erhalten wir regelmäßig Anfragen, DNS-Einträge mit sehr kurzen TTLs zu setzen – manchmal 60 Sekunden, manchmal sogar 5 Sekunden oder gar keine TTL. Der Grund, der uns dafür genannt wird, ist in der Regel derselbe: Wenn sich die IP-Adresse ändert, soll jeder sofort die neue Adresse sehen.

Das klingt logisch, funktioniert in der Praxis aber einfach nicht so.

DNS ist ein mehrschichtiges System – autoritative Server, rekursive Resolver, Client-Caches und manchmal sogar Anwendungs-Caches – und jede dieser Schichten kann sich unterschiedlich verhalten. DNS wurde in den 1980er Jahren entwickelt. Es ist einfach nicht realistisch, von einem so alten System mit so vielen unabhängigen Schichten zu erwarten, dass es sich so agil verhält.

Aus diesem Grund akzeptieren wir in unserem Umfang keine TTLs unter 3600 Sekunden mehr, und für NS-Sätze liegt der Standard bei 86400. Das mag „lang” klingen, spiegelt aber wider, wie DNS tatsächlich funktioniert, und nicht, wie man sich das wünschen würde.

Erwartung vs. Realität

• Erwartung: Bei einer TTL von 5 Sekunden erhalten alle Clients weltweit sofort die neue IP, wenn Sie die IP ändern.
• Realität:
  • Viele Resolver setzen ihre eigene minimale Caching-Zeit durch, sodass aus Ihren 5 Sekunden möglicherweise 30, 60 oder mehr werden.
  • Clients (Browser, Betriebssysteme, Anwendungen) speichern oft viel länger im Cache – oder ignorieren TTLs sogar komplett.
  • Die Prozesse zur tatsächlichen Aktualisierung von DNS-Einträgen sind selten schnell genug, um solche kurzen TTLs sinnvoll zu machen.
  • Ultrakurze TTLs führen nur dazu, dass die Clients die DNS-Infrastruktur überlasten, ohne das eigentliche Problem zu lösen.

Warum sie nicht funktionieren

Auf dem Papier klingt eine TTL von 5 oder 60 Sekunden nach einer guten Sache: Ändern Sie die IP im DNS-Eintrag, und die Clients sehen die Änderung fast sofort. In der Realität gibt es jedoch mehrere harte Einschränkungen, die solche Einstellungen unwirksam oder sogar kontraproduktiv machen.

Resolver-Mindestwerte

Viele rekursive Resolver wenden ihre eigene minimale Caching-Zeit an. Wenn Sie einen Eintrag mit einer TTL von 5 Sekunden konfigurieren, kann diese stillschweigend auf 30 oder 60 Sekunden erhöht werden – manchmal sogar noch mehr. Das Ergebnis: Die ultrakurze TTL wird außerhalb Ihres eigenen Servers nie wirklich wirksam.

Clientseitiges Caching

Selbst wenn ein Resolver Ihre niedrige TTL respektiert, tut dies der Client möglicherweise nicht. Browser, Betriebssysteme und Anwendungen speichern DNS-Antworten oft unabhängig voneinander im Cache, manchmal für Minuten oder Stunden, unabhängig davon, was die autoritative TTL angibt. Das bedeutet, dass Endbenutzer möglicherweise noch lange Zeit die „alte“ IP-Adresse auflösen.

Anwendungsverhalten

Einige Anwendungen implementieren ihre eigene DNS-Logik vollständig. In diesen Fällen ändert keine TTL-Einstellung – ob kurz oder lang – das Verhalten des Clients.

Belastung der Infrastruktur

Jede Abfrage, die das Caching umgeht, muss die nächste DNS-Ebene erreichen, meist bis zu Ihrem Server. Bei Zehntausenden von Datensätzen führt die Einstellung sehr kurzer TTLs zu einer dramatischen Vermehrung des Abfragevolumens. Das belastet Ihre DNS-Infrastruktur ohne Nutzen.

Cloud-basierte DNS-Dienste berechnen regelmäßig Millionen (oder Milliarden) von DNS-Anfragen, die sie verarbeiten. Eine so niedrige TTL-Einstellung verursacht also nicht nur eine hohe Auslastung, sondern kann auch erhebliche Kosten verursachen, ohne dass ein konsistenter Vorteil entsteht.

Inkonsistentes Verhalten

Hier fragen Sie sich vielleicht: Einerseits verbessern niedrige TTLs die Propagierung nicht. Andererseits verursachen sie eine höhere Auslastung. Wie kann beides zutreffen?

Die Antwort ist einfach: Client-Implementierungen sind inkonsistent. Einige führen ständig erneute Abfragen durch, andere kümmern sich überhaupt nicht darum. Der vermeintliche Vorteil einer niedrigen TTL – schnelle globale Propagierung – ist bestenfalls unzuverlässig. Und da Sie ohnehin immer für den Fall „oder nicht“ planen müssen, bringt Ihnen die niedrige TTL nichts außer mehr Lärm.

Kurz gesagt: Niedrige TTLs garantieren keine schnellere Propagierung, aber sie garantieren mehr Last und Komplexität.

Eine häufige Anfrage: Route 53 und 60-Sekunden-NS-Sets

Eine Anfrage, die wir immer wieder erhalten, ist, wenn jemand eine Zone an AWS Route 53 delegieren möchte und darauf besteht, dass die NS-Einträge eine TTL von 60 Sekunden haben sollen.

Oberflächlich betrachtet mag dies wie eine clevere Methode erscheinen, um „flexibel zu bleiben”. In Wirklichkeit macht es jedoch keinen Sinn. NS-Sätze ändern sich fast nie, und wenn doch, dann nur im Rahmen einer sorgfältig geplanten Migration. Es hat keinerlei Vorteile, sie jede Minute zu aktualisieren.

Tatsächlich fragen Resolver auf der ganzen Welt immer wieder denselben NS-Satz ab und belasten so die DNS-Infrastruktur ohne Grund. Die Erwartung ist, dass eine niedrige TTL die Agilität verbessert; in Wirklichkeit werden jedoch nur Ressourcen verschwendet, ohne dass eine schnellere Propagierung erreicht wird.

Ein Hinweis zu Route 53: Dies ist keine Kritik an Route 53 als DNS-Dienst – er ist zuverlässig, gut betrieben und für viele Anwendungsfälle eine vernünftige Wahl. Für DNS Zonen mit sehr vielen Anfragen kann er lediglich sehr teuer sein, da man anhand der Queries abrechnet. Aber wie jede Plattform hat auch diese Standardwerte und Muster, die einer genauen Prüfung bedürfen. Wenn man eine vorgeschlagene Konfiguration akzeptiert, ohne zu verstehen, warum, kann es zu Problemen kommen, unabhängig davon, welchen Anbieter man nutzt.

So macht man es richtig

Wenn das Ziel reibungslose Umstellungen oder die Minimierung von Ausfallzeiten ist, besteht die Lösung nicht darin, dauerhaft extrem niedrige TTLs festzulegen. Vielmehr geht es darum, TTLs strategisch zu planen und einzusetzen.

Verwenden Sie realistische Standardeinstellungen

Für den täglichen Betrieb sind TTLs im Bereich von 3600 Sekunden (eine Stunde) völlig ausreichend. Für NS-Einträge können bis zu 86400 Sekunden (ein Tag) angemessen sein. Diese Werte sorgen für Stabilität und Vorhersehbarkeit ohne unnötige Belastung.

TTLs vorübergehend senken

Wenn Sie wissen, dass eine Migration oder Umstellung bevorsteht, senken Sie die TTL für die entsprechenden Einträge im Voraus (z. B. ein oder zwei Tage vorher von 3600 auf 300). Sobald die Änderung abgeschlossen ist, erhöhen Sie die TTL wieder auf einen stabilen Wert.

Die Wahrheit ist: Die meisten Kunden respektieren eine kurze TTL – aber nicht alle, und Sie müssen immer für diejenigen planen, die dies nicht tun.

Planen Sie, improvisieren Sie nicht

DNS-Umstellungen sind aufgrund der Vorbereitung erfolgreich, nicht aufgrund einer magischen Zahl im TTL-Feld. Staging, doppelte Setups und klare Kommunikation vermeiden weitaus mehr Ausfallzeiten als eine TTL von 5 Sekunden jemals könnte.

Planen Sie Überschneidungen ein

Bei jeder Umstellung gibt es immer Kunden, die noch die alte Infrastruktur nutzen, während andere bereits die neue verwenden.

Wenn das inakzeptabel ist, verlassen Sie sich bei der Umstellung überhaupt nicht auf DNS. Verwenden Sie einen Load Balancer oder einen ähnlichen Mechanismus, mit dem Sie den Zeitpunkt der Umstellung kontrollieren können. Diese Tools sind deterministisch. DNS ist es nicht.

Fazit

Kurze TTLs werden oft mit den besten Absichten angefordert – aber sie liefern nicht das, was man sich davon erhofft. DNS ist kein Echtzeitsystem: Resolver legen Mindestwerte fest, Clients speichern nach ihren eigenen Regeln im Cache und Anwendungen ignorieren TTLs manchmal komplett.

Was kurze TTLs tatsächlich bewirken, ist eine zusätzliche Belastung der DNS-Infrastruktur und manchmal sogar zusätzliche Kosten. Was sie nicht bewirken, ist eine schnellere oder zuverlässigere Propagierung.

Der bessere Ansatz besteht darin, realistische Standardeinstellungen festzulegen, Umstellungen im Voraus zu planen und TTL-Anpassungen bei Bedarf als vorübergehendes Hilfsmittel zu verwenden. Mit der richtigen Vorbereitung kann DNS stabil und anpassungsfähig sein – ohne dem Mythos der Echtzeit-Aktualisierungen nachzujagen.