Zusammenfassung
- RFC 2182 erschien im Juli 1997 als BCP 16 und behandelte die Serverplatzierung als Frage der betrieblichen Zuverlässigkeit.
- Für die meisten Organisationszonen empfahl er drei Server, von denen mindestens einer deutlich entfernt stehen sollte.
- Die Empfehlung war kein Nachweis unabhängiger Stromversorgung, Routen, Anbieter oder tatsächlicher Erreichbarkeit.
Eine Zone konnte drei Nameserver veröffentlichen und praktisch trotzdem nur einen Weg zu einer Antwort haben. Wenn alle drei von derselben Zugangsleitung, demselben Gebäude oder derselben Stromversorgung abhingen, konnte ein einzelner Ausfall alle treffen. Die Zahl sah redundant aus; die Abhängigkeiten waren es nicht.
Dieses Betriebsproblem behandelten Robert Elz, Randy Bush, Scott Bradner und Michael Patton in RFC 2182, „Selection and Operation of Secondary DNS Servers“. Die IETF veröffentlichte ihn im Juli 1997 als Best Current Practice 16. Es war kein neues DNS-Protokoll. Das Dokument sollte die bereits vorgesehene Redundanz auch außerhalb der Zonendatei, im wirklichen Netz, wirksam machen.
Mehrere autoritative Server für eine delegierte Zone waren im DNS bereits vorgesehen. RFC 2182 unterschied zwei leicht zu verwechselnde Rollen: Der primäre Server hält die lokal gepflegten Zonendaten; ein sekundärer bezieht sie per Zonentransfer vom Primärserver. Resolver und übergeordnete Zone ordnen Antworten aber nicht nach dieser Unterscheidung. Für das übrige DNS sind es schlicht mehrere eingetragene autoritative Server. Ein sekundärer hilft nur, wenn Clients ihn erreichen, sobald ein anderer Server oder die gemeinsame Infrastruktur ausfällt.
Die Autoren gingen von Betriebsproblemen aus, die sie bereits beobachteten: schlecht ausgewählte sekundäre Server. Geografische Lage und unterschiedliche Netzverbindungen könnten Zuverlässigkeit und Leistung verbessern. Alle Server am selben Standort zu platzieren, bezeichneten sie ausdrücklich als schlechte Praxis. Der Ausfall einer Leitung, eines Standorts, Gebäudes, Raums oder der Stromversorgung konnte alle Server trennen. Entscheidend war nicht die Annahme, ein entfernter Rechner sei automatisch sicher, sondern die Frage, welche Fehler mehrere zugleich treffen konnten.
RFC 2182 empfahl drei Server für die meisten Organisationszonen; mindestens einer sollte deutlich von den anderen entfernt sein. Für höhere Zuverlässigkeit konnten vier oder fünf sinnvoll sein. Unbegrenzt mehr war nicht automatisch besser: Größere NS-Sätze machten DNS-Pakete umfangreicher und erhöhten die Chance unbemerkter Fehlkonfigurationen. Die Zahl war eine Faustregel innerhalb einer Platzierungsentscheidung, kein universeller Erfüllungswert.
Der Vorschlag machte auch eine praktische Abhängigkeit sichtbar: Jemand musste die entfernte Kopie betreiben. Der RFC beschrieb Organisationen ähnlicher Größe, die sich gegenseitig sekundären Dienst bereitstellten. Die ausgetauschten Zonendaten waren ohnehin öffentlich abrufbar und legten daher keine vertraulichen Informationen offen. So ließ sich Redundanz auf mehrere Betreiber verteilen, erforderte aber laufende Pflege von Transfers, Seriennummern und Erreichbarkeit.
Der BCP maß weder, ob Betreiber die Empfehlungen umsetzten, noch ob eine konkrete Konfiguration einen bestimmten Ausfall überstand. Eine veröffentlichte NS-Liste beweist nicht, dass zwei Anbieter verschiedene Upstreams nutzen, ihre Standorte unabhängige Stromversorgung haben oder Routen unter Belastung getrennt bleiben. „Drei Server“ belegt die Anzahl, nicht eine Prüfung der Ausfallpfade.
Das Dokument von 1997 enthält zudem eine später veraltete Aussage zu negativen DNS-Antworten. Es behauptete allgemein, negative Ergebnisse würden üblicherweise nicht zwischengespeichert. RFC 2308 standardisierte negatives Caching im folgenden Jahr; Erratum 4631 des RFC Editors bezeichnete die pauschale Aussage später als unzutreffend. Auch betriebliche Best Practices haben ein Datum und eine Wartungsgeschichte.
Die bleibende Erkenntnis von RFC 2182 ist genauer als eine magische Zahl: Redundanz hängt von Abhängigkeiten ab. Ein dritter Server zählt erst dann, wenn er verändert, was gemeinsam ausfallen kann.
Quellen
RFC 2182 / BCP 16 — „Selection and Operation of Secondary DNS Servers“.
RFC 1034 — „Domain Names—Concepts and Facilities“.
RFC 1035 — „Domain Names—Implementation and Specification“.
RFC 2308 — „Negative Caching of DNS Queries“.
Erratum 4631 des RFC Editors — Spätere Korrektur der pauschalen Aussage zu negativem Caching in RFC 2182.
IETF-40-Protokoll — DNS-Diskussion vom Dezember 1997.
ISC, BIND-Geschichte — Chronologie der BIND-8-Veröffentlichung.
RFC 1982 — Serial Number Arithmetic, zitiert zur Pflege von Zonennummern.
DNSIND-Entwurf -06 — Entwurfsstand vom Mai 1997 in der Geschichte von RFC 2182.
Heng Lu, Note 70 — Nur ein redaktioneller Blickwinkel, kein DNS-Historienbeleg.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
