Zusammenfassung

  • George Michaelson schrieb, sein DNS-Backup habe nur theoretisch existiert; beim Neustart des vermeintlichen Primärsystems stellte sich heraus, dass es die einzige Instanz war.
  • DHCP und IPv6-Router-Advertisements können mehrere Resolver-Adressen verteilen. Die Liste beweist jedoch weder Speicherung noch tatsächliche Umschaltung beim Client.
  • Ein verhältnismäßiger Nachweis trennt laufenden Endpunkt, Fehlerdomäne, verteilte Konfiguration, beobachteten Client-Zustand, nützliche Antwort, Richtliniengleichheit und Rückkehr.

George Michaelson schilderte am 9. September im APNIC Blog, wie er Pi-hole und AdGuard als hausinternen DNS-Dienst betrieb. Der Beitrag ist keine Störungsmeldung zu APNIC-Produktionsdiensten; die Seite weist die Ansichten dem Autor zu. Gerade deshalb ist die Beobachtung brauchbar. Michaelson hatte einen Backupplan, hatte ihn aber nicht umgesetzt. Als er den vermeintlich primären DNS-Dienst neu startete, fielen abhängige Geräte aus. Das Primärsystem war nicht eines von zweien. Es war das einzige.

Die Quelle nennt weder Störungsdauer noch vollständige Topologie, Geräteliste, Paketmitschnitt oder Sicherheitsfolge. Diese Lücken dürfen nicht mit Annahmen gefüllt werden. Der veröffentlichte Sachverhalt reicht aus, um Absicht und Betriebszustand zu trennen. Ein zweiter Resolver kann in einer Zeichnung stehen, ohne zu laufen. Er kann laufen, ohne dass seine Adresse verteilt wird. Zwei Adressen können verteilt sein, ohne dass jeder Client sie behält. Und ein erreichbarer Ersatz kann normale Namen beantworten, während lokale Sperr- oder Umleitungsregeln fehlen.

Die Resilienz fehlte schon vor dem Neustart

Der Neustart machte die Unterbrechung sichtbar. Die fehlende Reserve bestand vorher. Für die Wartungsentscheidung ist diese Reihenfolge entscheidend. Wer einen getesteten Ersatzpfad voraussetzt, hält das Abschalten eines Endpunkts für begrenzt. Existiert der Ersatz nur als Vorstellung, wird derselbe Eingriff zum Live-Test der Abhängigkeiten.

Michaelson beschreibt diese Abhängigkeiten: DNS-Neustarts stoppten andere Funktionen im Haus; Routeränderungen konnten das WLAN unterbrechen; eine Änderung der Router-DNS-Konfiguration wirkte auf DHCP. Seine drei Fragen betreffen deshalb nicht die Zahl der Geräte, sondern die abhängigen Komponenten, die tatsächliche Übernahme eines Ersatzdienstes und die Möglichkeit, den vorherigen Zustand wiederherzustellen.

Zwei Prozesse auf demselben Host teilen dessen Ausfall. Zwei Geräte an derselben Stromversorgung teilen den Stromausfall. Zwei Adressen aus demselben Router teilen Router- und Konfigurationsfehler. Zwei Kopien einer falschen Vorlage teilen den administrativen Fehler. Unabhängigkeit muss benennen, welchen Ausfall wenigstens ein Pfad überlebt.

Eine verteilte Liste ist noch kein Laufzeitnachweis

RFC 2132 lässt DHCPv4-Option 6 eine nach Präferenz geordnete DNS-Serverliste übermitteln. RFC 3646 definiert für DHCPv6 eine Liste aus einer oder mehreren IPv6-Adressen rekursiver DNS-Server. RFC 8106 erlaubt RDNSS-Adressen in IPv6-Router-Advertisements und versieht sie mit einer Lebensdauer; der Wert null beendet ihre Nutzung.

Damit lässt sich belegen, was der Router oder DHCP-Dienst in einem bestimmten Moment ausgeben wollte. Nicht belegt ist, was Fernseher, Telefon, Laptop oder Sensor gespeichert und ausgewählt haben. RFC 6419 dokumentierte geringe Einheitlichkeit im Umgang von Desktop-Systemen mit mehreren DNS-Listen: pro Schnittstelle oder systemweit, unterschiedliche Wahl bei mehreren eingegangenen Listen und unterschiedliche Rückfallverfahren. Das Dokument ist keine aktuelle Erhebung in Michaelsons Haushalt. Es genügt aber, um einen Router-Screenshot nicht mit dem Zustand aller Clients gleichzusetzen.

RFC 9520 hält fest, dass ein Stub-Resolver mehrere rekursive Adressen haben und eine Anfrage bei einem anderen Server oder über einen anderen Transport wiederholen kann. Daraus folgt keine Garantie für einen bestimmten Client oder Zeitpunkt. Ein Auflösungsfehler liegt dort erst vor, wenn keiner der verfügbaren Server nützliche Daten zur Anfrage liefert. Zwischen „zwei Adressen wurden angekündigt“ und „der Nutzer erhielt während des Ausfalls eine nützliche Antwort“ bleibt also ein zu beobachtender Betriebsmechanismus.

Erreichbarkeit kann ohne lokale Richtlinie zurückkehren

Der beschriebene Dienst war mehr als ein neutraler Weiterleiter. Michaelson leitete einige bekannte Namen auf nicht gerootete IP-Adressen um. Deshalb gehört Richtliniengleichheit in den Test. Der Ersatzresolver kann allgemeine Namen auflösen, aber eine lokale Antwort oder Sperre nicht übernehmen. Die Verbindung funktioniert wieder, während der Zweck des Eigenbetriebs verloren geht.

Die Quelle belegt weder einen tatsächlichen Richtlinienverlust noch einen Sicherheitsvorfall. Zulässig ist nur die engere Folgerung: Der Test muss Auflösung und erwartetes lokales Verhalten getrennt prüfen. Antwortet der Ersatz mit anderer Richtlinie, ist das ein Teilerfolg.

Kleiner Haushalt, kleiner Nachweis

Der stärkste Einwand ist die Verhältnismäßigkeit. Der Beitrag sagt selbst, dass viele Haushalte gelegentliche Ausfälle hinnehmen können und keine Unternehmensredundanz benötigen. Zwei Resolver zu pflegen, Regeln abzugleichen und verschiedene Clients zu testen kann aufwendiger sein als die vermiedene Unterbrechung.

Ein kurzer Wartungsvermerk reicht: Resolver A und B samt Standort und gemeinsamen Abhängigkeiten; die über DHCPv4, DHCPv6 oder RDNSS ausgegebenen Adressen und Gültigkeiten; der Zustand einiger unterschiedlicher Clients; ein kurzes kontrolliertes Entfernen des bevorzugten Resolvers; eine normale Anfrage und eine Anfrage mit lokaler Sonderbehandlung; soweit sichtbar der antwortende Endpunkt; anschließend die Wiederherstellung.

Der Test deckt nicht jedes Gerät, jede Anfrage und jede Fehlerart ab. Er schließt einen begrenzten Fall und nennt die offenen Stellen. Aus dem Plan wird Reserve, wenn der Ersatz läuft. Aus Reserve wird Resilienz, wenn Clients ihn im Fehlerfall nutzen. Wartbar wird sie, wenn auch die Rückkehr belegt ist.

Quellen