Zusammenfassung

  • Die Empfehlung von drei gelisteten Servern galt nur zusammen mit der Forderung, mindestens einen geografisch und topologisch deutlich von den anderen zu trennen.
  • Eine veröffentlichte, aber unerreichbare Adresse zwingt verteilte Resolver zu Versuchen, Wartezeiten und Wiederholungen und kann damit die wahrgenommene Zuverlässigkeit verschlechtern.
  • NS-Eintrag, autoritative Antwort, SOA-Seriennummer und abgeschlossener Zonentransfer belegen verschiedene Stufen; keiner garantiert allein gleiche aktuelle Daten oder Ende-zu-Ende-Verfügbarkeit.

Mehrzahl im DNS, Einzahl in der Infrastruktur

RFC 2182 erschien im Juli 1997 als BCP 16. Sein Ausgangspunkt war nicht die Anzahl der Prozesse, sondern ihr Zweck: Zoneninformationen sollten verfügbar bleiben, wenn ein Server ausfiel oder nicht erreichbar war. Mehrere Maschinen im selben Raum erfüllten diese Aufgabe nur gegenüber einem einzelnen Hardwaredefekt. Raum, Gebäude, Strom und gemeinsamer Link blieben eine einzige Fehlerdomäne.

Darum verlangte das Dokument geografische und topologische Streuung. Entfernung schützt vor lokalen physischen Ereignissen. Verschiedene Netzpfade schützen vor Link-, Routing- oder Providerfehlern. Ein entfernter Standort kann dennoch am selben Transit hängen; zwei Marken können dieselbe Anlage und dasselbe Kontrollsystem nutzen.

Drei war folglich kein Zertifikat. Zwei sorgfältig platzierte Server konnten genügen, doch ein längerer Ausfall ließ dann nur einen übrig. Für typische Organisationszonen empfahl die BCP drei, davon mindestens einen deutlich entfernt; bei höheren Anforderungen vier oder fünf. Erst die Abhängigkeiten gaben der Zahl ihre Bedeutung.

Die unbrauchbare Adresse lässt andere warten

Die zu einem NS-Namen veröffentlichten Adressen mussten aus dem Gebiet erreichbar sein, in dem die Information verwendet wurde. Ein Rechner hinter einer Firewall, an einer häufig getrennten Leitung oder mit einer nur intern brauchbaren Adresse wurde durch den Eintrag nicht zum öffentlichen Ersatzserver.

Ein Resolver erkennt Unerreichbarkeit nur durch den fehlgeschlagenen Versuch. Er sendet, wartet und wiederholt, weil Schweigen zunächst auch Paketverlust bedeuten kann. Die Anwendung kann vorher aufgeben. Später prüfen andere Resolver dieselbe Adresse erneut. So verteilt der Betreiber die Diagnosearbeit an Teilnehmer, die den Fehler nicht beheben können.

Der Text von 1997 behauptete pauschal, ein fehlendes Ergebnis werde nicht gecacht. Das redaktionelle Erratum 4631, das für eine Dokumentaktualisierung vorgemerkt ist, berücksichtigt RFC 2308: negative Antworten können je nach Serververhalten und Konfiguration gespeichert werden. Die Korrektur ändert nicht den Kern. Eine unerreichbare Autorität erzeugt weiterhin unnötige Versuche und Verzögerungen.

Auch die Weitergabe von Referral-Daten spielte eine Rolle. Erreichbarkeit nur vom ersten Resolver genügte nicht. Ein Adress-RRset musste nach RFC 2181 vollständig behandelt werden; eine schlechte Adresse durfte nicht selektiv versteckt oder mit eigenem TTL versehen werden. Unterschiedliche interne und externe Sichtbarkeit verlangte konsistente DNS-Sichten und Namen.

Zusätzliche Kopien vergrößern die Wartungsfläche

Viele Server vergrößern Antworten und nähern sie Paketgrenzen. Vor allem vervielfachen sie Konfiguration, Transferbeziehung, Softwarestand und Zuständigkeit. Jede zusätzliche Instanz kann unbemerkt falsch oder defekt sein.

Stealth Server boten eine gezielte Alternative. Lokale autoritative Kopien konnten interne Anfragen bei externer Trennung beantworten, ohne alle global zu listen. Ihre Veröffentlichung würde externe Resolver bei Ausfall des gemeinsamen Standortlinks nutzlos jede lokale Maschine prüfen lassen. Lokaler Nutzen ist nicht dasselbe wie eine globale Verfügbarkeitszusage.

Redundanz braucht eine gepflegte Version

Ein Secondary nutzt die SOA-Seriennummer für seine Updateentscheidung. Der Primary muss sie bei jeder Änderung erhöhen. Wurde sie versehentlich zu hoch gesetzt, kann ein direktes Herabsetzen dazu führen, dass bereits aktualisierte Secondaries die Korrektur als älter ignorieren.

RFC 2182 beschreibt deshalb eine stufenweise Korrektur innerhalb der Arithmetik von RFC 1982. Nach jedem gültigen Sprung muss der Betreiber warten und alle relevanten Secondaries prüfen, bevor er durch den Zahlenumlauf zum gewünschten kleineren Absolutwert gelangt. Die Kontrolle jeder Zwischenstufe ist wichtiger als die Beispielzahlen.

Ein NS-Eintrag beweist die Veröffentlichung eines Namens. Eine Antwort beweist, dass ein Prozess antwortete. Eine SOA-Abfrage zeigt die an einem Punkt beobachtete Nummer. Ein Transferende belegt den Transportabschluss. Offen bleiben Laden, tatsächliches Servieren, Inhaltsgleichheit, unabhängige Infrastruktur und Anwendungserfolg.

Auch die Sicherheitsbetrachtung blieb begrenzt. Der RFC wollte bestehende DNS-Risiken weder lösen noch verschärfen und warnte, dass ein kompromittierter Secondary Hosts der Domain gefährden könne. Verteilung schafft nur dann Resilienz, wenn sie keine unzuverlässige Autorität hinzufügt.

Der bleibende Wert von RFC 2182 liegt im Beweismaßstab. Die Zone benennt Autorität. Der Betrieb muss zusätzlich zeigen, was gemeinsam ausfallen kann, wer jede Adresse erreicht und welche Version tatsächlich ausgeliefert wird.

Quellen

  1. RFC 2182 — Selection and Operation of Secondary DNS Servers
  2. Informationsseite zu RFC 2182
  3. RFC 1982 — Serial Number Arithmetic
  4. RFC 2181 — Clarifications to the DNS Specification
  5. RFC 2308 — Negative Caching of DNS Queries
  6. Errata zu RFC 2182