Zusammenfassung

  • RFC 5395 ordnete DNS-OpCodes, RCODEs, Header-Bits, Daten-TYPEs, QTYPEs, Meta-TYPEs, CLASSes und AFSDB-Untertypen getrennten Zuweisungsverfahren und Risiken zu.
  • Unassigned, Reserved und Private Use sind keine Varianten von „frei“. Private Use erlaubt lokale Bedeutung ohne weltweite Kollisionsvermeidung; ein unassigned Wert benötigt weiterhin die zuständige Zuweisung.
  • Eine belastbare Prüfung verbindet Feldkontext, Zahl, Autoritätsweg, datierten Registerstand, Verhalten der Implementierung, Interpretation des Gegenübers und Ergebnis für den Nutzer, ohne diese Nachweise zu verschmelzen.

Ein Registereintrag besitzt ein Datum

RFC 5395 wurde 2008 als BCP 42 veröffentlicht. RFC 6195 ersetzte ihn 2011, vor allem mit einer Änderung der öffentlichen Review-Liste. RFC 6895 ersetzte RFC 6195 im Jahr 2013, vereinfachte das RRTYPE-Verfahren und schloss das Register der AFSDB-Untertypen. Der für diese Recherche eingefrorene IANA-Stand nennt den 28. August 2026 als letzte Aktualisierung.

Wer eine Tabelle aus dem Jahr 2008 gegen den Stand von 2026 hält, vergleicht keine konkurrierenden Wahrheiten. Die erste Quelle belegt damalige Politik und damaligen Bestand. Die zweite enthält zusätzlich fast zwei Jahrzehnte autorisierter Aktionen. Der historische Text bleibt für Herkunft und Entscheidungslogik wichtig, ist aber kein aktuuelles Inventar.

Auch die Aussage „laut IANA“ braucht einen präzisen Beleg. Gemeint sein müssen Registername, Abrufzeit und Darstellungsform. HTML, XML, Text-Export, unternehmensinterner Cache und daraus generierter Code können nach einem fehlerhaften Synchronisationslauf auseinanderlaufen. Ihre Übereinstimmung ist zu messen, nicht vorauszusetzen.

Eine reproduzierbare Freigabe speichert deshalb Snapshot und Hash zusammen mit dem ausgelieferten Artefakt. So lässt sich später unterscheiden, ob eine Entscheidung nach damaligem Stand korrekt war, ob das Register sich anschließend änderte oder ob die lokale Projektion bereits beim Rollout veraltet war.

Die leere Zeile übertrug keine Befugnis

Unassigned beantwortet eine enge Frage: Für diesen Platz ist im betrachteten Register noch keine öffentliche Zuweisung verzeichnet. Daraus folgt weder, dass ein Implementierer ihn nehmen darf, noch welches Verfahren seine Bedeutung schaffen könnte. RFC 5395 legte gerade kein universelles Vergabemodell über alle DNS-Felder.

OpCodes, RCODEs, Header-Bits, RRTYPEs, CLASSes und AFSDB-Untertypen hatten unterschiedliche Knappheit, Altlasten und Policies. Je nach Stelle waren Standards Action, IETF Review oder Expert Review erforderlich. Reserved bedeutete eine stärkere Sperre. Private Use delegierte lokale Bedeutung und verzichtete bewusst auf globale Eindeutigkeit.

Ein zufällig gewählter unassigned Wert leiht sich zukünftigen Registerraum. Wird derselbe Wert später regulär vergeben, trifft die öffentliche Bedeutung auf installierte Geräte mit privater Semantik. Das frühere Deployment erhält dadurch kein Gewohnheitsrecht; es erzeugt lediglich Migrationskosten und politischen Druck.

Jede Änderung sollte daher Register, Feld, Zahl, Status, Policy, Normreferenz, Entscheider, Kollisionsdomäne und Rückbauplan nennen. „War noch frei“ ist kein Genehmigungsprotokoll.

Gleich große Felder sind keine gemeinsame Zahlenwelt

DNS besitzt mehrere numerische Räume. Dass zwei Werte in 16 Bit passen, macht sie nicht austauschbar. Daten-TYPE, QTYPE und Meta-TYPE unterscheiden sich sogar innerhalb verwandter Felder durch ihre Rolle: persistente Daten, Abfrageauswahl oder transiente Steuerung.

RCODE 16 zeigt die Bedeutung des Wire-Kontexts besonders klar. Im OPT-Zusammenhang steht er als BADVERS für eine nicht unterstützte Version, im TSIG-Zusammenhang als BADSIG für eine fehlgeschlagene Signatur. RFC 6895 dokumentiert zudem bei 9 „Not Authoritative“ beziehungsweise „Not Authorized“, abhängig von der Umgebung.

Ein Monitoring-Feld rcode=16 kann numerisch korrekt und diagnostisch unbrauchbar sein. Versionsproblem und Authentisierungsproblem führen zu anderen Verantwortlichen und Maßnahmen. Gespeichert werden müssen Basis- oder Erweiterungsfeld, umschließender Record, effektive Breite, Peer und geltende Spezifikation.

Dasselbe gilt für Datenmodelle. Eine generische Spalte code lädt zu falschen Joins über Register hinweg ein. Namespace und Feldposition gehören zur Identität. Wer sie im Dashboard ausblendet, muss sie wenigstens in der Beweisschicht erhalten.

Ein scheinbar freies Bit konnte Altzustand tragen

RFC 5395 warnte, dass manche Implementierungen Antworten durch Kopieren des Query-Headers initialisierten und dabei nicht alle Bits löschten. Ein nur in der Anfrage sinnvoller Wert konnte deshalb in der Antwort zurückkehren. Eine neue Antwortsemantik an dieser Stelle hätte den kopierten Rest als absichtliches Signal erscheinen lassen.

Das Z-Bit besaß noch ältere Geschichte. Einzelne frühe Systeme verstanden es in einer Anfrage als Forderung nach einer Antwort vom primären Server. Obwohl dieser Gebrauch beim Schreiben des RFC als weitgehend verschwunden galt, blieb für eine Neuzuweisung Standards Action nötig.

Der Feldplan ist somit keine vollständige Landkarte des installierten Codes. Private Tests können zeigen, dass ausgewählte Produkte ungefährlich sind; sie können unbekannte Implementierungen nicht ausschließen. Die öffentliche Zuweisung zwingt die Behauptung in eine überprüfbare Koordination.

Running code hat Vorrang als Realitätsbeleg, nicht als Eigentumstitel. Ein funktionierender Prototyp beweist Verhalten eines Systems. Er beseitigt weder historische Nebenwirkungen anderer Systeme noch ersetzt er die Autorität, globale Bedeutung zu vergeben.

Private Use endet an einer durchsetzbaren Grenze

Für RRTYPE reicht Private Use von 65280 bis 65534. Zwei Standorte dürfen unabhängig 65300 verwenden. Der eine kodiert einen Gesundheitsstatus, der andere ein Policy-Token. Solange beide Systeme getrennt bleiben, sind ihre Tests valide.

Nach Kopplung, Firmenfusion oder Nutzung eines gemeinsamen DNS-Dienstes trägt dieselbe Nummer unvereinbare RDATA. Kein öffentlicher Eintrag entscheidet den Konflikt, weil genau diese Koordination im Private-Use-Modell fehlt. RFC 8126 legt Kollisionsvermeidung innerhalb des beabsichtigten Bereichs in die Hand der Nutzer.

Die vernünftige Antwort ist nicht, private Werte abzuschaffen. Betreiber müssen Teilnehmer, Lebensdauer, Filter, Telemetrie, Austrittsbedingungen und Umnummerierung definieren. Sobald breite Interoperabilität erforderlich wird, ist ein regulärer Zuweisungsweg nötig.

Ein neuer Partner oder eine neue Außenverbindung ist deshalb kein rein geschäftliches Ereignis. Er verändert die Kollisionsdomäne. Bleibt diese Änderung unsichtbar, wird aus einem kontrollierten Experiment schleichend öffentliches Protokollverhalten.

Expert Review vergab Identität, nicht Einsatzbereitschaft

RFC 5395 führte für RRTYPE ein DNS-spezifisches Expert-Review-Verfahren ein, das RFC 6895 später vereinfachte. Der Antragsteller reicht eine vollständige Vorlage ein; IANA bestellt einen Experten; Zustimmung oder begründete Ablehnung folgen; akzeptierte Vorlagen werden öffentlich archiviert.

Ein Daten-TYPE muss nach RFC 3597 als unbekannter RR behandelbar sein. Ein Meta-TYPE muss optional verarbeitet und sicher verworfen werden können. Unklare Anträge, falsche DNS-Annahmen, Verstöße gegen diese Bedingungen oder unnötig große Werteblöcke können abgelehnt werden.

Die Zustimmung beweist, dass eine Vergabeentscheidung nach diesem Verfahren stattfand. Sie beweist nicht, dass autoritative Server die Eingabe annehmen, Secondaries sie übertragen, Provisioning sie erhält, Resolver sie ausgeben, Anwendungen sie verstehen oder der Dienst funktioniert.

Umgekehrt ist eine gelungene Produktdemo kein Registerbeleg. Die Trennung ermöglicht dem Register, kollisionsfreie Identität vor allgemeiner Implementierung zu reservieren, und verpflichtet Betreiber, Reservierung nicht als ausgelieferte Fähigkeit darzustellen.

Undurchsichtige Bytes können ohne Wirkung überleben

RFC 3597 definierte für unbekannte RRs eine generische Textform: TYPE plus Dezimalzahl, danach \#, Oktettlänge und hexadezimale RDATA. Regeln zu Kompression und Gleichheit helfen älteren Servern, unbekannte Daten zu speichern, zu übertragen und zu vergleichen.

Das ist eine wichtige Evolutionsschicht. Zwischenkomponenten müssen nicht jede neue Semantik kennen. Dennoch ist eine fehlerfreie Rundreise nur ein Verwahrungsnachweis. Ein Secondary beweist Transfer, ein Resolver Abruf, eine API Ausgabe. Erst die konsumierende Anwendung beweist Interpretation und Ergebnis.

Die Testkette sollte Eingabe, Parsing, Wire-Format, Transfer, Cache, API, Anwendungslogik und Nutzerwirkung separat messen. Eine bekannte TYPE in generischer Schreibweise erhält nach dem Parsing weiterhin ihre typspezifische Behandlung; Darstellung darf bekannte Semantik nicht in vermeintlich harmlose Opazität verwandeln.

Gerade dadurch lässt sich das eingangs beschriebene Scheitern erklären. Alles im DNS-Pfad kann korrekt arbeiten, während der Dienst schweigt. Das ist kein Widerspruch, sondern eine fehlende letzte Quittung.

Evidenzgrenze

Die eingefrorenen Quellen belegen Text und Nachfolge von RFC 5395, 6195 und 6895, die Regeln für unbekannte RRs aus RFC 3597, Registerbegriffe aus RFC 8126 und den erfassten IANA-Stand. Sie belegen keine heutige Unterstützung eines benannten Produkts, Betreiberadoption, reale Kollision oder Ausfallursache.

Belastbar bleibt eine schmale Aussage: Lokale Wahl, autorisierte Vergabe, IANA-Eintrag, Byte-Erhalt, Anwendungsverständnis und Nutzerergebnis sind verschiedene Zeitpunkte der Nutzbarkeit. Wer nur eine Zahl oder ein grünes Feld besitzt, hat nicht automatisch die übrigen Nachweise.