Zusammenfassung

  • Revision 01 eines individuellen Internet-Drafts dokumentiert zwei am 20. August 2026 per Expert Review abgeschlossene DNS-RRTYPE-Zuweisungen: UNECE erhielt den Dezimalwert 69, ISO den Wert 70. Die Einträge stehen im IANA-Register; der Entwurf ist weder RFC noch ein von DNSOP angenommenes Arbeitsdokument.
  • Die RDATA übernimmt Kennung und Code aus dem jeweiligen externen Regelwerk, lässt Ausgabejahr, Änderungen und Korrigenda jedoch absichtlich weg. Für historische Auslegung verweist der Entwurf auf die bei RRSIG-Beginn geltende Registerfassung, ohne diese Fassung im signierten Datensatz zu benennen oder zu hashen.

Zwei Uhren laufen nebeneinander. Die erste gehört zur DNS-Signatur: Beginn, Ablauf und erneute Signierung eines RRsets lassen sich exakt bestimmen. Die zweite gehört zu einer externen Codeliste, deren Herausgeber Werte ergänzt, zurückzieht oder unter eigenen Regeln wiederverwendet. Die neuen Typen 69 und 70 verbinden beide Systeme, synchronisieren ihre Uhren aber nicht.

Im IANA-Register der DNS-Parameter steht UNECE seit dem 20. August 2026 unter 69 und ISO unter 70. Die aktuelle Revision 01 von draft-woodcock-faltstrom-external-registry-rrtypes wurde am 9. September hochgeladen. Ihr Anhang und der offizielle Versionsvergleich erklären, dass gegenüber Revision 00 nur die inzwischen erfolgten Zuweisungen und das Expert Review vom 20. August ergänzt wurden.

Der institutionelle Status ist enger als die fertigen Codepunkte vermuten lassen. Datatracker, die Dokumenthistorie und der API-Datensatz führen die Arbeit als aktiven individuellen Internet-Draft. Es gibt keine RFC-Nummer, keinen Stream und keinen verantwortlichen Area Director. „Standards Track“ im Kopf ist die Zielangabe der Autoren, keine Annahme durch eine IETF-Arbeitsgruppe.

Die Nummer ist zentral, die Semantik bleibt föderiert

RFC 6895 Abschnitt 3.1 ordnet neue DNS-RRTYPEs dem Verfahren Expert Review zu. RFC 8126 Abschnitt 4.5 beschreibt, wie benannte Fachleute einen Antrag anhand der einschlägigen Kriterien beurteilen. Die öffentlichen Antragsunterlagen für UNECE und ISO zeigen diesen Weg. Er schafft eindeutige Typnummern. Er bestätigt weder die sachliche Richtigkeit noch die Rechtswirkung oder Aktualität eines Codes im Inneren.

Der Entwurf zieht die Kompetenzgrenze ausdrücklich. IANA führt kein zweites Verzeichnis der UNECE- oder ISO-Werte. Ein UNECE-Datensatz bezeichnet etwa Empfehlung 16 für UN/LOCODE oder Empfehlung 20 für Maßeinheiten; ein ISO-Datensatz verweist beispielsweise auf 3166-1, 4217 oder 639. Der eigentliche Code wird unverändert übernommen. Herausgeber einer Zone dürfen keinen eigenen Wert erfinden. Empfänger sollen eine unbekannte Kennung oder einen unbekannten Code unverändert transportieren und anzeigen, statt daraus einen ungültigen DNS-Datensatz zu machen.

Damit bleiben die UNECE-Empfehlungslisten und die ISO-3166-Pflegeoberfläche dort, wo die fachliche Autorität liegt. RFC 6116 kennt ein verwandtes Muster: ENUM nutzt E.164-Ländercodes, ohne die Nummernhoheit bei IANA nachzubauen.

Diese Zurückhaltung verhindert einen konkurrierenden Normgeber. Sie erzeugt aber eine Abhängigkeit, die eine Signatur allein nicht konserviert. Ein DNS-RRset kann noch vorliegen, obwohl sich Veröffentlichungsseite, Tabellenstand oder Rücknahmeregel der externen Stelle geändert haben.

Ein stabiler Bezeichner verschweigt die Ausgabe

In der RDATA werden Jahreszahlen, Amendments und Corrigenda aus den UNECE- und ISO-Kennungen bewusst ausgelassen. ISO 3166-1 soll auch nach einer neuen Ausgabe dieselbe Drahtkennung bleiben; Gleiches gilt für eine UNECE-Empfehlung. Das ist gute Voraussetzung für Vorwärtskompatibilität, beseitigt aber den direkten Verweis auf einen konkreten historischen Registerstand.

Der Entwurf setzt deshalb Bedingungen für die Veröffentlichung: Die externe Liste muss zu diesem Zeitpunkt aktiv, kostenlos öffentlich zugänglich und zitierfähig sein. Künftige Spezifikationen nach demselben Modell sollen außerdem Rücknahme und Wiedervergabe durch den externen Verwalter erläutern. Eine einheitliche Annahme wäre falsch. Nach Darstellung des Entwurfs bleiben gelöschte oder missbilligte UNECE-Werte sichtbar; zurückgezogene ISO-4217-Währungen tragen ein Rücknahmedatum; ausgemusterte ISO-639-Kennungen werden nicht neu vergeben; bei ISO 3166 gibt es eine lange Sperrfrist, aber auch historische Wiedervergabe.

Ein unveränderter Code kann folglich „weiter gültig“, „zurückgezogen, aber nachvollziehbar“, „reserviert“ oder „inzwischen anders belegt“ heißen. Genau diese Zeitsemantik stammt nicht von IANA und nicht aus dem DNS-Feld.

Der Signaturbeginn ist kein Editionszeiger

Für historisch relevante Fälle empfiehlt der Entwurf, den Stand des externen Registers heranzuziehen, der beim Beginn des abdeckenden RRSIG galt. Als Ordnungsregel ist das plausibel. Als Provenienznachweis ist es unvollständig.

RFC 4034 Abschnitt 3.1.5 definiert Signature Inception als den frühesten Zeitpunkt, zu dem ein RRSIG sein RRset authentisieren darf. Weitere Felder nennen Ablauf, Algorithmus, Key Tag und Unterzeichner. Weder UNECE-Ausgabe noch ISO-Edition, Abrufadresse oder Inhaltsdigest gehören dazu. RFC 9364 ordnet diese Felder in die Herkunftsauthentisierung und Integrität von DNSSEC ein; es macht aus DNSSEC kein Archiv externer Normen.

Ein Betreiber kann unveränderte RDATA neu signieren. Dadurch springt der RRSIG-Beginn vor, obwohl Behauptung und externer Code gleich bleiben. Umgekehrt kann der externe Verwalter eine neue Liste herausgeben, während eine ältere Signatur noch gültig ist. Der Zeitpunkt sagt einem Empfänger, wo er suchen soll. Er sagt nicht, welches Artefakt der Empfänger tatsächlich gefunden und welche Rücknahmeregel er angewandt hat.

Das ist keine Meldung über einen Vorfall. Keine Quelle belegt eine Fehlinterpretation oder gescheiterte Einführung. Es ist die erwartbare Folge einer klug getrennten Autorität: Kryptografie sichert die DNS-Aussage, nicht die wandelbare Definition außerhalb des DNS.

Ein lokaler Auflösungsbeleg schließt die Nachweislücke

Wer eine folgenreiche Entscheidung trifft, sollte einen kleinen Auflösungsbeleg für das externe Register speichern. Er enthält RRTYPE und Diskriminator, Rohcode beziehungsweise Rohwert, externen Verwalter, exakte Ausgabe oder alternativ Abruf-URI, Abrufzeit und Inhaltsdigest, RRSIG-Beginn und -Ablauf, Unterzeichner und Validierungsergebnis, angewandte Rücknahme- oder Wiedervergaberegel, Behandlung unbekannter Werte, Version der Herausgeberrichtlinie und die lokale Entscheidung, die das Ergebnis verwendete.

Dieser Beleg zertifiziert das externe Register nicht. Er dokumentiert nur den tatsächlich benutzten Evidenzpfad. Verschwindet eine Webseite, lässt sich der gelesene Inhalt über Digest und zulässige Archivkopie zuordnen. Wird ein Code neu vergeben, bleibt die damalige Zeitregel sichtbar. Wird dasselbe RRset neu signiert, entsteht nicht rückwirkend eine neue semantische Herkunft.

Der Ansatz folgt dem Prinzip der kleinsten gemeinsamen Festlegung aus Heng Lus Minimum Initial Specification: Nur die Abhängigkeitsgrenze wird deterministisch, Ausführung und Politik bleiben dezentral. Aus The Policy Mirror kommt die Forderung, ein wirksames automatisiertes Ergebnis aus Regel, Autorität und Evidenz rekonstruieren zu können. Der Beleg ist mein redaktioneller Vorschlag, keine Vorgabe von IETF, IANA, UNECE oder ISO.

Die Typvergabe ist abgeschlossen, die Spezifikation noch in Arbeit. Beides kann gleichzeitig wahr sein. Für verantwortlichen Einsatz kommt eine dritte Wahrheit hinzu: Der externe Registerstand, der einer signierten Zeichenfolge Bedeutung gab, muss auffindbar bleiben.

Quellen