Zusammenfassung

  • Die Mitteilung vom 19. Mai 1997 verlegte einen experimentellen Rootserver von NSI zu LINX und übertrug RIPE NCC den K-root-Betrieb; die veröffentlichte Adresse lautete danach 193.0.14.129.
  • Das war ein Wechsel des Betriebsorts, keine neue DNS-Wurzel. Ein Ausweichsystem in Amsterdam kam kurz darauf hinzu; Anycast wurde 2003 eingeführt.

Was die Änderungsmitteilung festhielt

Die Ankündigung liegt im DNS-Arbeitsgruppenarchiv von RIPE. Sie besagt, dass einer der experimentellen Server für den Punkt „.“ von Network Solutions (NSI) nach London verlegt und bei der London Internet Exchange (LINX) untergebracht wurde. RIPE NCC sollte K-root betreiben. Für k.root-servers.net wurde die neue Adresse 193.0.14.129 veröffentlicht. Laut Mitteilung hatten IANA und InterNIC die Aktualisierung der Rootserver-Informationsdateien abgestimmt.

Die mitgelieferte Liste ist ein zweiter, andersartiger Beleg. Sie führt K-root mit dem Standort LINX und RIPE NCC als Betreiber auf; als zugehörige Version der Rootzone nennt sie 1997051700. Serveradresse und Zonenstand sind verschiedene Angaben. Die Datei ist kein Paketmitschnitt und belegt nicht, was jeder rekursive Resolver im Cache hatte. Eine neue Rootzone kündigt sie ebenfalls nicht an.

Rootserver machen Daten der Rootzone erreichbar. Der Standort oder die Adresse eines Servers sagt, wo sein Dienst erreichbar ist; daraus folgt nicht, dass sich die gelieferten Zonendaten geändert haben. Aus „ein Rootserver zog um“ wird schnell „die DNS-Wurzel zog um“. Damit werden Serviceort und Namensraum verwechselt. Die Mitteilung von 1997 nennt einen Server und dessen Betreiber, aber keine Übertragung der weltweiten Namensautorität nach London.

London war ein Standort, keine zweite Wurzel

Der Standort war für den Betrieb relevant: LINX bot einen Londoner Austauschpunkt, der sich vom früheren Standort bei NSI unterschied. Die Mitteilung nennt geografisch breiter verteilten Dienst als Ziel. Die spätere Geschichte des Root Server System Advisory Committee (RSSAC) datiert den Start von K-root bei LINX auf den 19. Mai 1997. Ein Satz von Hot-Standby-Servern sei kurz darauf bei AMS-IX in Amsterdam eingerichtet worden. Ein genaues Datum für diesen zweiten Schritt nennt der Bericht nicht.

Der erste Londoner Standort war noch kein Anycast-Netz. RIPE-268 schlug 2003 vor, K-root an mehreren Punkten der Internet-Topologie unter derselben IP-Adresse bereitzustellen. RSSAC datiert K-roots Anycast-Einsatz ebenfalls auf 2003 und verknüpft ihn mit dem Amsterdamer Ausweichsystem. Londoner Hauptstandort, Amsterdamer Standby und Anycast sind aufeinanderfolgende Schritte, aber keine einzelne Einführung. Wer sie zusammenzieht, projiziert die Architektur von 2003 auf 1997 zurück.

Auch die institutionellen Rollen waren verteilt. RIPE NCC betrieb K-root, LINX stellte den Londoner Standort, und IANA sowie InterNIC koordinierten die veröffentlichten Informationen. Das beschreibt den Dienstbetrieb. Es belegt weder, dass RIPE NCC den Inhalt der Rootzone bestimmte, noch dass Großbritannien DNS-Namen regierte oder mehrere öffentliche Wurzeln bestanden. RFC 2826 erläutert später das technische Konzept eines einzigartigen öffentlichen Namensraums mit koordinierten Rootservern. Die RFC hilft bei der Einordnung, dokumentiert aber nicht die Entscheidung von 1997.

Was die Chronologie trägt

Die zeitgenössische Mitteilung belegt die geplante Verlegung, den Betreiber, die neue Adresse und die aktualisierte Serverliste. RSSAC ergänzt das Startdatum und die späteren Standby- und Anycast-Schritte. RIPE-268 beschreibt den folgenden Vorschlag. Zusammen zeigen die Quellen, wie Rootdienst von einem geografisch anderen Austauschpunkt aus betrieben werden konnte, während der öffentliche Namensraum eine einzige Wurzel behielt.

Die Quellen messen weder die Latenz vor und nach dem Umzug noch das Londoner Anfragevolumen oder vermiedene Ausfälle. RIPE-268 nennt Konnektivität und Redundanz als Gründe für das spätere Design, aber das ist keine Wirkungsmessung für 1997. Die belastbare Aussage bleibt begrenzt: Der Betriebsort eines Rootservers änderte sich; Inhalt und Autorität der öffentlichen Rootzone sind eine andere Frage. Eine Adresse weist auf einen Servicepunkt hin, nicht auf eine vollständige Karte der Namensraumkontrolle.

Quellen