DNS als stiller Single Point of Failure: TTL, sekundäre Nameserver und ein sauberer Änderungsprozess

DNS gehört zu den Diensten, über die im Normalbetrieb niemand spricht. Es läuft, Domains lösen auf, Anwendungen finden ihre Backends. Genau deshalb wird DNS bei Architekturentscheidungen oft übersprungen: Es steht in keinem Projektplan, hat selten ein eigenes Budget und wird gerne dort belassen, wo die Domain vor Jahren registriert wurde. Fällt die Namensauflösung aus oder ist eine Zone falsch konfiguriert, sind gleichzeitig Website, E-Mail, VPN-Zugänge und interne Schnittstellen betroffen. Der Server läuft dann einwandfrei und ist trotzdem nicht erreichbar.

Dieser Beitrag beschreibt, welche Punkte im DNS-Betrieb tatsächlich über Verfügbarkeit entscheiden und wie ein Änderungsprozess aussieht, der ungeplante Ausfälle vermeidet.

Warum DNS mehr ist als ein Eintrag beim Registrar

Bei einer Domain sind drei Rollen beteiligt, die häufig vermischt werden. Der Registrar verwaltet die Registrierung der Domain und meldet der Registry, welche Nameserver zuständig sind. Der DNS-Hoster betreibt diese Nameserver und beantwortet die Anfragen. Und die Zone selbst ist der eigentliche Datenbestand mit A-, AAAA-, MX-, TXT- und CNAME-Einträgen.

Diese drei Rollen können bei einem Anbieter liegen, müssen es aber nicht. Wer sie trennt, gewinnt Flexibilität: Ein Wechsel des Webhostings zwingt dann nicht dazu, gleichzeitig die Domain umzuziehen. Wer sie zusammenlegt, hat weniger Schnittstellen, aber auch eine größere Abhängigkeit. Wichtig ist vor allem, dass im Unternehmen dokumentiert ist, wer welche Rolle innehat und wer dort Zugriff besitzt. Bei Störungen ist das die erste Frage, und sie lässt sich überraschend oft nicht schnell beantworten.

TTL: der unterschätzte Hebel

Die TTL gibt an, wie lange Resolver eine Antwort zwischenspeichern dürfen. Sie bestimmt damit, wie schnell eine Änderung im Internet ankommt und wie lange ein Fehler nachwirkt. Eine hohe TTL reduziert Anfragen und macht die Auflösung robuster, wenn die autoritativen Server kurzzeitig nicht erreichbar sind. Eine niedrige TTL erlaubt schnelle Umschaltungen, etwa bei einer Migration oder einem Failover.

In der Praxis bewährt sich ein gestaffeltes Vorgehen. Records, die sich nie ändern, dürfen eine lange TTL haben. Records, die an einer geplanten Änderung beteiligt sind, bekommen einige Tage vorher eine kurze TTL, damit alte Werte aus den Caches verschwunden sind, bevor umgeschaltet wird. Nach der Umstellung und einer Beobachtungsphase wird die TTL wieder erhöht.

Der typische Fehler besteht darin, die TTL erst am Umstellungstag zu senken. Das wirkt nicht rückwirkend: Resolver, die den alten Wert mit der alten TTL geholt haben, behalten ihn bis zum Ablauf. Die TTL muss gesenkt werden, bevor die eigentliche Änderung ansteht, nicht gleichzeitig mit ihr.

Redundanz durch sekundäre Nameserver

Eine Zone sollte von mindestens zwei Nameservern beantwortet werden, die nicht im selben Netz und idealerweise nicht beim selben Betreiber stehen. Das ist keine theoretische Vorsichtsmaßnahme. Störungen bei DNS-Anbietern betreffen alle Kunden gleichzeitig, und ohne zweiten unabhängigen Pfad hilft weder ein hochverfügbarer Webserver noch ein gutes Monitoring.

Technisch lässt sich das über einen klassischen Primary-Secondary-Aufbau lösen. Der primäre Server hält die Zone, die sekundären Server holen sie per Zonentransfer ab und antworten autoritativ. Für die Delegation bei der Registry werden alle Nameserver eingetragen. Wichtig ist, dass die Zonentransfers eingeschränkt sind, damit nicht jeder beliebige Host die vollständige Zone abziehen kann, und dass die Seriennummer im SOA-Record bei jeder Änderung erhöht wird, sonst aktualisieren die Secondaries nicht.

Was oft vergessen wird

Redundanz nützt wenig, wenn die sekundären Server zwar existieren, aber nie geprüft werden. Wenn ein Zonentransfer seit Monaten scheitert, beantwortet der Secondary irgendwann veraltete Daten oder fällt nach Ablauf der Expire-Zeit ganz aus. Eine regelmäßige Kontrolle, ob alle autoritativen Server dieselbe Seriennummer und dieselben Records ausliefern, gehört deshalb ins Monitoring.

Den Registrar-Zugang absichern

Die Kontrolle über die Domain ist wertvoller als der Zugriff auf einzelne Server. Wer die Delegation ändern kann, lenkt sämtlichen Verkehr um, kann E-Mails abfangen und sich über die Domainvalidierung TLS-Zertifikate ausstellen lassen. Der Registrar-Account verdient damit dieselbe Sorgfalt wie ein privilegierter Serverzugang.

• Zwei-Faktor-Authentifizierung für alle Konten beim Registrar aktivieren.
• Transfer Lock setzen, damit die Domain nicht ohne Weiteres zu einem anderen Registrar wechseln kann.
• Eine funktionale Adresse als Kontakt hinterlegen, die nicht auf der eigenen Domain liegt, damit sie bei einer DNS-Störung erreichbar bleibt.
• Ablaufdaten und Verlängerungen überwachen, statt sich auf Erinnerungsmails zu verlassen.
• Zugänge beim Personalwechsel genauso entziehen wie Serverzugänge.

Ergänzend lohnt ein CAA-Record. Er legt fest, welche Zertifizierungsstellen für die Domain überhaupt ausstellen dürfen, und begrenzt damit den Schaden, falls jemand eine Validierung missbraucht.

Änderungen wie Deployments behandeln

DNS-Änderungen werden häufig ad hoc im Webinterface geklickt. Das geht lange gut und irgendwann schief, weil ein Tippfehler in einem MX-Record niemandem auffällt, bis die Zustellung stockt. Ein geordneter Änderungsprozess kostet wenig und verhindert genau diese Klasse von Fehlern.

1. Zone vor jeder Änderung exportieren und ablegen, damit ein Rückweg existiert.
2. Änderung schriftlich festhalten: welcher Record, alter Wert, neuer Wert, Grund, geplanter Zeitpunkt.
3. TTL der betroffenen Records rechtzeitig vorher senken.
4. Nach dem Ausrollen gegen mehrere öffentliche Resolver prüfen, nicht nur gegen den eigenen.
5. Beobachtungszeit einplanen und erst danach die TTL wieder anheben.

Wer Zonen als Textdateien in einem Repository pflegt und automatisiert ausrollt, bekommt Versionierung, Review und Rollback ohne zusätzlichen Prozess. Für Umgebungen mit vielen Domains ist das der deutlich ruhigere Weg. Für wenige Domains reicht ein dokumentiertes Vorgehen mit Export und Vier-Augen-Prinzip.

Monitoring: nicht nur die Website prüfen

Ein Check, der nur eine URL aufruft, meldet DNS-Probleme erst, wenn schon alles hängt. Sinnvoller ist es, die Namensauflösung selbst zu überwachen. Dazu gehören Abfragen gegen jeden einzelnen autoritativen Nameserver statt nur gegen den nächstbesten, ein Abgleich der Seriennummern zwischen Primary und Secondaries sowie eine Kontrolle der Records, die für E-Mail relevant sind. Wenn DNSSEC im Einsatz ist, kommt die Überwachung der Signaturgültigkeit dazu, denn abgelaufene Signaturen führen zu harten Auflösungsfehlern, die sich nicht durch einen Reload beheben lassen.

Ebenso hilfreich ist ein Blick von außen: Ein Resolver im eigenen Netz kennt möglicherweise interne Einträge oder liefert aus einem Cache, der die Realität beschönigt.

Einordnung

DNS ist kein Projekt, sondern Betrieb. Die entscheidenden Maßnahmen sind unspektakulär: dokumentierte Zuständigkeiten, mindestens zwei unabhängige autoritative Server, bewusst gesetzte TTL-Werte, ein abgesicherter Registrar-Zugang und Änderungen, die nachvollziehbar dokumentiert und geprüft werden. Zusammengenommen verhindern sie einen Großteil der Ausfälle, die später als Netzwerkproblem fehlinterpretiert werden.

Wenn Sie unsicher sind, wie Ihre Zonen aktuell aufgestellt sind, beginnen Sie mit einer Bestandsaufnahme: Welche Domains gibt es, wo sind sie registriert, welche Nameserver sind delegiert, wer hat Zugriff. Diese Liste ist die Grundlage für alles Weitere und in vielen Unternehmen der erste Punkt, der fehlt.