Ray Bellis und die Richtung einer Pflicht

Zusammenfassung

• RFC 5625 erschien im August 2009 als BCP 152 mit einem einzigen Autor; die BCP-152-Seite weist eine Unterreihe mit genau einem RFC aus. RFC 8490 ist ein Proposed Standard von März 2019 mit sechs Autoren.
• Die starken Verben des ersten Textes verbieten Eingriffe, die des zweiten stiften einen geteilten Zustand. Keiner von beiden erreicht jemanden, der die Annahme verweigert; das Register bewahrt die Nummer, nicht den Betrieb.

Wo eine Pflicht hinzeigt

Der Unterschied lässt sich an der Grammatik ablesen. Im ersten Dokument zeigen die stärksten Sätze nach außen und halten etwas fern: Der Vermittler zwischen Endgerät und Namensdienst soll die Finger von dem lassen, was er nicht einordnen kann. Abschnitt 4.1 verlangt, dass ein Proxy unbekannte DNS-Flags ignoriert und die Pakete unverändert weiterleitet; Abschnitt 4.4 verlangt, dass er das TC-Bit setzt, wenn er eine Antwort einseitig kürzen muss; Abschnitt 4.5 verlangt, dass er Pakete mit TKEY-Ressourceneinträgen weiterleiten kann (RFC-5625-Text).

Was positiv gewünscht ist, steht schwächer da. Abschnitt 3 empfiehlt, so transparent wie möglich zu sein. Abschnitt 4.4.1 sagt, eine über TCP eingegangene Anfrage solle über TCP weitergeleitet und nicht zuerst über UDP versucht werden. Abschnitt 5.2 empfiehlt für die beschriebene Option einen leeren Vorgabewert. Das ist keine Zaghaftigkeit, sondern eine Rechnung mit der Lebensdauer von Firmware: Ein Gerät, das heute verkauft wird, ist in Betrieb, wenn der Namensdienst längst weitergezogen ist. Die einzige Regel, die diesen Horizont übersteht, lautet, den Weg nicht zu verstellen.

Im zweiten Dokument zeigen die stärksten Sätze nach innen und errichten etwas, das es vorher nicht gab. Abschnitt 5.1 verbietet dem Server, DSO-Anfragen oder unidirektionale Nachrichten zu beginnen, bevor eine DSO-Sitzung beiderseitig errichtet ist. Abschnitt 5.1.1 verbietet einem DSO-fähigen Server, auf eine Keepalive-Anfrage mit DSOTYPENI zu antworten, weil das Keepalive-TLV zwingend zu implementieren ist. Abschnitt 5.4.1 behandelt eine DSO-Antwort mit der Nachrichten-ID null als schwerwiegenden Fehler, der das sofortige Abbrechen der Verbindung erzwingt (RFC-8490-Text).

Drei Sätze, und es entsteht eine Institution zu zweit: Die Sitzung existiert, weil beide sie errichtet haben. Ein Ablehnungscode verschwindet aus dem Repertoire, weil ein anderes Teil zwingend ist. Eine ungültige Kennung ist keine Warnung, sondern ein Ende. Der Text legt fest, was ein Verhalten bedeutet; er legt nicht fest, dass es geschieht. Und die schwächeren Sätze lehren beide Seiten, Stille zu lesen: dreißig Sekunden warten, die Gegenstelle als nicht DSO-fähig vermerken, wenn der Server die Verbindung fallen lässt.

Zwei Unterschriftenzeilen, zwei Träger

Die Autorenzeilen sagen etwas über die Träger der Arbeit. Der erste Text nennt R. Bellis von Nominet UK, hervorgegangen aus der Arbeitsgruppe DNSEXT und aus dem Entwurf draft-ietf-dnsext-dnsproxy; das ist im Datatracker als Seitenzusammenfassung dokumentiert, nicht als vollständige Revisionsgeschichte (Datatracker zu RFC 5625).

Der zweite Text verteilt die Verantwortung auf sechs Namen und fünf Organisationen: Bellis für ISC, Cheshire für Apple, beide Dickinson für Sinodun, Lemon für Nibbhaya Consulting, Pusateri ohne Anbindung. Er aktualisiert außerdem zwei ältere Dokumente, RFC 1035 und RFC 7766. Wer einen Zustand zwischen zwei Programmen verbindlich machen will, braucht offenbar mehr als einen Namen im Kopf der Seite.

Die leere Errata-Seite als schwaches Signal

Am 18. Oktober 2026 zeigten die Errata-Seite zu RFC 5625 und die zu RFC 8490 keinen Eintrag, und keine der Informationsseiten verwies auf ein ablösendes oder nachfolgendes Dokument. Das ist eine Aussage über den Stand dieser Seiten an diesem Tag, mehr nicht.

Denn eine leere Seite hat zwei Lesarten mit identischem Gesicht: Der Text hat der Nutzung standgehalten, oder niemand hat eine Korrektur eingereicht. Von außen sind sie nicht zu unterscheiden. Dasselbe gilt für die Entstehungsgeschichte: Die Einträge im Datatracker zu RFC 8490 und zu RFC 5625 lagen als Zusammenfassungen vor, nicht als vollständige Revisionsfolgen, sodass nur die halbe Kette sichtbar wird. Man erkennt die Arbeitsgruppen DNSEXT und DNSOP, nicht aber, welcher Entwurf welchen Satz erzeugt hat.

Und der wichtigste Punkt: Belege für Implementierung wurden nicht gefunden. Dieser Text behauptet nicht, dass RFC 5625 die Weiterleitung in Heimroutern verändert hat, und nicht, dass DSO in einem ausgelieferten Resolver läuft. Das ist eine Frage an Software, und Software hat in dem geprüften Material keine Spur hinterlassen.

Was das Register bewahrt

Die IANA-Registratur der DNS-Parameter führt OpCode 6 als DNS Stateful Operations mit Verweis auf RFC 8490 und daneben eine Tabelle der DSO Type Codes mit 0x0001 KeepAlive, 0x0002 RetryDelay und 0x0003 EncryptionPadding. Drei Zeilen, vergeben nach Verfahren, gehalten von einer Verwaltungsfunktion, die nicht davon abhängt, wer den Text geschrieben hat.

Das ist der dauerhafte Teil. Die Zuschreibung eines RFC ist ein datierter Akt; ein Eintrag im Register wird noch gelesen, wenn der Autor Arbeitgeber, Branche und Interesse gewechselt hat. Aber die Dauer gehört dem Register, nicht dem Antragsteller. Die Registratur bewahrt, dass es den Code gibt, nicht dass ihn jemand sendet.

Der Umfang des Kontrollierbaren

Es bleibt ein kleines, prüfbares Verzeichnis dessen, was Ray Bellis kontrollierte. Er kontrollierte die Formulierung: welche Pflicht ein MUST bekam und welche ein RECOMMENDED blieb, und besonders die Entscheidung, das stärkste Verb gegen Schaden statt für ein Merkmal einzusetzen. Er kontrollierte unter fünf Mitautoren die Wahl, die Sitzung als Vorbedingung statt als Höflichkeit zu behandeln. Er kontrollierte die Einreichung, die diese Sätze in ein Register brachte. Das sind wirkliche Handlungen, einer benannten Person zurechenbar und im Text sichtbar.

Nicht kontrollierte er den Teil, der entscheidet, ob das Gewicht hat. Ein Implementierer liest RFC 8490, rechnet die Kosten des Sitzungszustands gegen den Fahrplan seiner Firmware und lehnt ab. Kein Satz des Dokuments erreicht ihn, und gerade deshalb trägt das Register, was die Autorschaft nicht trägt.