Beim Root-Test von Jon Postel im Jahr 1998 ging es um Zonentransfers, nicht um DNS-Abfragen

Zusammenfassung

• Jon Postels E-Mail vom 28. Januar 1998 bat Root-Sekundärserver, eine Kopie der Zone von DNSROOT.IANA.ORG zu beziehen. Sie sollte der A-Root-Kopie entsprechen; die Regeln für Änderungen an der Root-Zone blieben unverändert.
• Am 3. Februar erklärte Postel den Verifikationstest für abgeschlossen und bat die Betreiber, wieder A-Root zu verwenden. Die Nachrichten dokumentieren Aufforderungen, nicht die Konfiguration jedes Betreibers.

Ein DNS-Dienst, zwei Arten von Verkehr

Ein Resolver, der einen Namen abfragt, und ein Sekundärserver, der seine Zonen-Kopie aktualisiert, erledigen verschiedene Aufgaben. Der Resolver sendet eine DNS-Abfrage an einen autoritativen Server. Der Sekundärserver bezieht die Daten, die er später bereitstellt, über eine separate Transferbeziehung. Beide Rollen können auf derselben Maschine laufen, sind aber nicht dieselbe Netzwerkoperation.

Diese Trennung war bereits Bestandteil des DNS-Betriebsmodells. RFC 1034 beschreibt einen primären Server, der Änderungen koordiniert, und Sekundärserver, die die SOA-Seriennummer prüfen und bei einer Erhöhung eine aktuelle Kopie beziehen. RFC 1035 definiert AXFR als Anfrage zur Übertragung einer vollständigen Zone. Eine Resolver-Abfrage nach einem Datensatz ist keine AXFR-Anforderung für die Root-Zone.

Im Januar 1998 konnte dieselbe Maschine als Root-Server Abfragen beantworten und zugleich als Quelle dienen, von der andere Root-Server ihre Daten aktualisierten. Postels Anfrage betraf die zweite Rolle. Er bat Resolver im Internet nicht darum, ihre üblichen Root-Abfragen an den IANA-Rechner zu senden.

Die E-Mail beschrieb eine eng begrenzte Transferanfrage

Die erhaltene E-Mail trägt das Datum 28. Januar 1998 und den Betreff „root zone secondary service“. Postel bat die Sekundärserver der Root-Domain, die Zone per Zonentransfer direkt von DNSROOT.IANA.ORG unter 198.32.1.98 zu beziehen. Die dortigen Daten sollten eine exakte Kopie der damals auf A.ROOT-SERVERS.NET verfügbaren Zone sein. Außerdem stellte er klar, dass sich weder die Richtlinien noch die Verfahren zur Änderung der Root-Zone ändern würden.

Der Satz zur Reichweite ist so wichtig wie der Servername. Die Anweisung galt nur für die Root-Zone. Betreiber, die andere Zonen einschließlich Top-Level-Domains sekundär bereitstellten, sollten ihre bisherigen Quellen weiterverwenden. Die E-Mail schlug somit eine Änderung an einem Replikationspfad vor, keine Umleitung des gesamten DNS-Dienstes und keinen Austausch aller vorgelagerten Beziehungen.

Im selben Archiv liegt eine Presseerklärung Postels. Darin beschrieb er den Test als Neuordnung des Flusses von Root-Zonen-Informationen. Der Inhalt der Zone werde weiterhin auf die gleiche Weise beschlossen und vorbereitet. Das sind zwei getrennte Aussagen: Die Daten sollten gleich bleiben, während ein anderer IANA-Server als Quelle für Sekundärkopien getestet werden sollte. Die Dokumente zeigen weder die Konfiguration jedes Sekundärservers noch das Ergebnis jedes Transfers.

Der Test berührte zugleich eine andere administrative Frage: Wer durfte Änderungen an den Einträgen selbst genehmigen? Die Januar-E-Mail ließ diese Verfahren ausdrücklich unverändert. Eine Transferquelle kann eine Kopie liefern, ohne damit zum Urheber aller darin enthaltenen Einträge zu werden. Die verfügbaren Nachrichten belegen nicht, dass IANA während des Tests eine neue Root-Zone bearbeitete oder veröffentlichte.

Eine andere Quelle ist keine Umleitung von DNS-Abfragen

Der Vorgang lässt sich leicht missverstehen, weil A-Root zwei Rollen hatte: Der Server beantwortete als einer der Root-Server Abfragen und galt zugleich als etablierte Quelle für die Root-Zonendatei. Beide Funktionen waren mit derselben Maschine verbunden. Das Transferprotokoll erlaubte es jedoch, die Verteilungsquelle von den Servern zu unterscheiden, die Resolvern antworteten.

Die mögliche Wirkung lässt sich als bedingte Schlussfolgerung formulieren. Bezieht ein Sekundärserver eine identische Zonenkopie und lädt sie korrekt, ändert der Wechsel der Quelle allein nicht die Datensätze, die ein Resolver erhält. Die archivierte E-Mail sagt, dass die IANA-Kopie identisch sein sollte; sie enthält aber weder einen Vergleich für jeden Server noch Abfragemessungen, die diese Bedingung überall belegen.

In einer späteren Anhörung vor dem US-Kongress erklärte NSI, das Unternehmen habe im Rahmen seiner Vereinbarung mit der Regierung als „primärer“ Root-Zonen-Server gehandelt. Zwischen den dreizehn Betreibern hätten keine Verträge bestanden; die übrigen Betreiber seien nicht verpflichtet gewesen, die Datei täglich abzurufen. Diese Aussage des Unternehmens hilft einzuordnen, dass „primär“ eine betriebliche Anordnung bezeichnete und keinen Vertragsbefehl an jeden Sekundärserver. Sie zeigt nicht, wer Postels Bitte 1998 annahm.

Die Rückkehrbitte grenzt den Vorgang ein

Am 3. Februar erklärte Postel in einer Nachricht mit dem Betreff „root zone transfer verification completed“ den Test für abgeschlossen und bat die Betreiber, die Zone wieder von A-Root zu beziehen. Auch diese Bitte galt nur für die Root-Zone. Die spätere Geschichte des Root-Server-Systems RSSAC-023v2 berichtet, Postel habe Jim Koda und Paul Vixie gebeten, für den Test einen primären Root-Server an der ISI aufzubauen und zu betreiben. Danach habe er mehrere Betreiber aufgefordert, die Zone von dort zu beziehen, und wenige Tage später alle Betreiber um die Rückkehr zum vorherigen primären Server gebeten.

Die spätere Darstellung bestätigt die Abfolge, nennt aber nur „mehrere“ Betreiber. Weder sie noch die erhaltenen E-Mails enthalten eine Liste der Betreiber, die ihre Konfiguration änderten, ein vollständiges AXFR-Protokoll oder Belege dafür, wann jeder Betreiber zu A-Root zurückkehrte. Eine Aufforderung belegt eine Absicht, nicht deren Ausführung durch jeden Empfänger.

Auch die Auswirkungen auf den Dienst lassen sich anhand der Quellen nicht messen. Postels Presseerklärung drückte großes Vertrauen in einen unterbrechungsfreien Übergang aus; Vertrauen ist jedoch keine Telemetrie. Den Nachrichten liegen weder Abfrageverläufe noch Ausfallprotokolle oder unabhängige Vergleiche aller aktiven Kopien bei.

Quellen

Die ereignisnahen Belege sind die archivierten Kopien von Postels Anfrage vom 28. Januar und seiner Rückkehrbitte vom 3. Februar. Das Archiv enthält einen PGP-Signaturblock, dessen Gültigkeit dieser Beitrag nicht unabhängig geprüft hat. Die RSSAC-Rückschau liefert eine spätere institutionelle Darstellung. RFC 1034 und RFC 1035 definieren den Transfermechanismus, nicht die Konfiguration jedes Betreibers im Jahr 1998. NSIs Darstellung findet sich im Protokoll einer Anhörung des Justizausschusses des US-Repräsentantenhauses und wird dem Unternehmen zugeschrieben.