TL;DR
DNS-basiertes Failover verteilt Anfragen auf erreichbare Ziele, kann bestehende Verbindungen aber nicht umleiten und wirkt wegen Caching nicht sofort überall. TTL, rekursive Resolver, Betriebssysteme und Anwendungen beeinflussen die Umschaltzeit. Anycast DNS und Multi-Provider-DNS erhöhen die Steuerbarkeit und Resilienz, beseitigen diese Unsicherheit jedoch nicht vollständig.
Einleitung
DNS-basiertes Failover wird häufig mit einer schnellen Umschaltung gleichgesetzt: Ein Ziel ist nicht erreichbar, der DNS-Eintrag ändert sich, und Clients verwenden automatisch ein alternatives Backend. Diese Annahme ist technisch zu einfach. DNS verteilt Namensauflösungen, nicht bereits etablierte Verbindungen. Außerdem bestimmen TTL, rekursive Resolver, lokale DNS-Caches und anwendungsspezifische Zwischenspeicher, wann eine Änderung tatsächlich wirksam wird. Dadurch entsteht ein zentraler Trade-off: DNS bietet eine breite Steuerungsmöglichkeit über viele Clients und Provider hinweg, aber keine präzise Kontrolle über den Zeitpunkt jeder einzelnen Umschaltung.
1. DNS steuert neue Auflösungen, nicht bestehende Verbindungen
Bei einem DNS-basierten Failover wird die Antwort auf eine Namensauflösung verändert. Ein Resolver kann statt der bisherigen IP-Adresse künftig ein alternatives Ziel zurückgeben. Das hilft bei neuen Verbindungen, erreicht aber keine bereits laufenden TCP- oder TLS-Sessions. Diese bleiben bestehen, bis sie regulär beendet werden oder wegen eines Fehlers abbrechen.
Die tatsächliche Umschaltzeit hängt deshalb nicht nur von der Erkennung des Ausfalls ab. Auch die Dauer der bestehenden Verbindungen, Retries auf Anwendungsebene und das Verhalten von Clients beeinflussen die Unterbrechung. Ein kurzlebiger HTTP-Request reagiert anders als eine langlebige API-Verbindung oder ein Streaming-Kanal.
Für die Betriebsplanung ist diese Unterscheidung entscheidend: DNS-Failover ist ein Mechanismus für neue Verbindungsaufnahmen. Es ersetzt weder Session-Management noch Applikations-Failover. Anwendungen müssen mit temporär nicht erreichbaren Zielen umgehen können, etwa durch Timeouts, Wiederholungslogik und idempotente Requests.
2. TTL ist eine Obergrenze, kein Umschaltversprechen
Die TTL legt fest, wie lange eine DNS-Antwort grundsätzlich zwischengespeichert werden darf. Eine niedrige TTL kann die Zeit bis zur erneuten Abfrage verkürzen. Sie garantiert jedoch nicht, dass alle Clients nach Ablauf exakt zu diesem Zeitpunkt eine neue Antwort erhalten. Resolver können Abfragen zeitlich versetzt durchführen, und Endgeräte oder Anwendungen können zusätzliche Caches verwenden.
Eine hohe TTL reduziert normalerweise DNS-Abfragen und kann die Infrastruktur entlasten. Im Fehlerfall verlängert sie aber die Bindung an ein nicht erreichbares Ziel. Eine sehr niedrige TTL verbessert die Reaktionsfähigkeit, erhöht jedoch die Abhängigkeit von DNS-Erreichbarkeit und die Anzahl der Auflösungen. Außerdem bleibt die TTL wirkungslos, wenn eine Anwendung die Adresse selbst länger zwischenspeichert.
Der sinnvolle Wert ergibt sich daher aus dem Ausfallmodell, nicht aus dem Wunsch nach möglichst schneller Umschaltung. Für kritische Services sollte getestet werden, wie rekursive Resolver, Betriebssysteme, Libraries und Clients tatsächlich reagieren. Erst diese Beobachtung macht aus einer konfigurierten TTL eine belastbare Betriebserwartung.
3. Anycast DNS und Multi-Provider-DNS erweitern die Resilienz
Anycast DNS verteilt DNS-Anfragen über mehrere erreichbare Netzwerkknoten und nutzt Routing, damit Resolver einen geeigneten Antwortpunkt erreichen. Das kann die Erreichbarkeit des DNS-Dienstes verbessern und die Abhängigkeit von einem einzelnen Standort reduzieren. Die nachgelagerte Failover-Entscheidung bleibt davon getrennt: Auch ein global erreichbarer DNS-Dienst kann weiterhin Antworten liefern, die bei einzelnen Clients noch aus dem Cache stammen.
Multi-Provider-DNS verteilt den autoritativen DNS-Betrieb über mehrere Anbieter. Dadurch entsteht eine zusätzliche Ausfallgrenze, beispielsweise wenn ein DNS-Provider selbst nicht erreichbar ist. Gleichzeitig steigen die Anforderungen an Konfiguration, Monitoring, Änderungsprozesse und Konsistenz. Ein zweiter Provider ist kein automatisches Failover, wenn Zonen, Health Checks oder Delegationen nicht abgestimmt betrieben werden.
Eine Edge-Plattform wie die ayedo Edge Cloud verbindet Anycast DNS und Multi-Provider-DNS mit einer eigenen Netzwerk-Infrastruktur und einem eigenen Autonomous System. Das stärkt die Unabhängigkeit im öffentlichen Eingangspfad. Die grundsätzliche Cache-Latenz von DNS bleibt jedoch bestehen und muss in der Architektur berücksichtigt werden.
4. Health Checks erkennen Zustände, aber nicht jede Nutzerwirkung
Health Checks können prüfen, ob ein Ziel erreichbar ist oder auf definierte Anfragen korrekt reagiert. Auf dieser Grundlage lässt sich die DNS-Antwort anpassen und Traffic zu einem anderen Ziel lenken. Zwischen erkannter Störung und wirksamer Umschaltung liegen jedoch mehrere Schritte: Der Check muss auslösen, die autoritative Antwort muss aktualisiert werden, Resolver müssen neu abfragen, und Clients müssen die neue Adresse verwenden.
Dabei ist die Wahl des Prüfpunktes wichtig. Ein Check aus einer einzelnen Netzwerkposition kann regionale Routing- oder Providerprobleme übersehen. Ein Ziel kann für den Health Check erreichbar sein, während eine Anwendung funktional gestört ist. Umgekehrt kann ein temporärer Fehler zu unnötigen Umschaltungen führen. Schwellenwerte, Wiederholungen und Rückkehrlogik beeinflussen deshalb die Stabilität des Failovers.
Betrieblich braucht DNS-Failover nachvollziehbare Telemetrie: Welche Ziele gelten als gesund, welche Antworten werden aktuell autoritativ ausgegeben, und wie lange halten Resolver alte Daten? Die ayedo Edge Cloud stellt Backend Health Checks und Failover als Teil ihrer Edge-Funktionen bereit. Für die Bewertung der Ausfallzeit müssen Betreiber dennoch DNS-Caching und Clientverhalten separat betrachten.
Praxis- und Betriebsszenario
Ein Unternehmen betreibt eine API an zwei Standorten und veröffentlicht sie unter einem gemeinsamen DNS-Namen. Ein Health Check erkennt, dass Standort A keine gültigen Antworten mehr liefert. Die autoritative DNS-Konfiguration verweist daraufhin auf Standort B. Neue Clients, deren Resolver keine alte Antwort mehr verwenden, erreichen B. Andere Clients erhalten weiterhin A, solange ihre Resolver- oder Anwendungscaches gültig sind. Bereits bestehende Verbindungen zu A schlagen zusätzlich fehl, bis die Anwendung einen Retry ausführt oder die Verbindung neu aufbaut.
Ein niedriger TTL-Wert reduziert die erwartete Verzögerung, eliminiert sie aber nicht. Ein Anycast-DNS- und Multi-Provider-Ansatz erhöht die Verfügbarkeit der DNS-Steuerung, ersetzt jedoch kein Applikationsverhalten für Timeouts, Retries und Sessions.
FAQ
Ist eine TTL von wenigen Sekunden gleichbedeutend mit einem sofortigen Failover?
Nein. Sie begrenzt die vorgesehene Cache-Dauer, garantiert aber keine exakte Wirksamkeit. Resolver, Betriebssysteme und Anwendungen können die Umschaltung unterschiedlich schnell übernehmen.
Kann DNS-Failover bestehende Verbindungen auf ein anderes Backend verschieben?
Nein. DNS beeinflusst neue Auflösungen. Bestehende TCP-, TLS- oder Anwendungssitzungen müssen auslaufen, fehlschlagen oder durch die Anwendung neu aufgebaut werden.
Was leistet Anycast DNS zusätzlich?
Anycast DNS verbessert die Erreichbarkeit des DNS-Eingangspunkts über verteilte Netzwerkpfade. Es beseitigt jedoch weder alte DNS-Antworten in Caches noch Fehler in den Backends.
Fazit
DNS-basiertes Failover ist ein wirksames Steuerungsinstrument für neue Verbindungen, aber kein präziser Schalter für den gesamten Datenverkehr. TTL und DNS-Caching bestimmen, wie schnell Änderungen sichtbar werden; Health Checks bestimmen, wann ein Problem erkannt wird. Anycast DNS und Multi-Provider-DNS erhöhen die Resilienz des Steuerungspfads. Die ayedo Edge Cloud ordnet diese Mechanismen in eine verteilte Edge-Plattform ein. Für belastbare Ausfallzeiten müssen Unternehmen zusätzlich Sessions, Retries und Anwendungscaches planen.