Zusammenfassung

  • draft-levine-dnsextlang-14 schlägt TXT-basierte RRTYPE-Beschreibungen vor. Das Dokument ist ein individueller Internet-Draft, kein RFC und kein bereits betriebener IANA-Dienst.
  • X kennzeichnet nötige Sonderverarbeitung und erlaubt Ablehnung, wenn sie fehlt. Das Kennzeichen liefert weder Code noch Implementierungsnachweis.
  • DNSSEC belegt Herkunft und Integrität eines RRsets unter lokaler Vertrauenspolitik. Semantik, Versionsgleichheit, Parser-Sicherheit und Freigabe müssen separat nachgewiesen werden.

Ein grünes Validierungssignal kann an der falschen Stelle stehen. Der TXT-Eintrag ist signiert, ein Provisionierungsformular erscheint, die Grammatik wird akzeptiert. Noch ist aber unbekannt, ob genau dieses Server-Binary die erwarteten RDATA-Oktette erzeugt und sie nach Speicherung, Signierung, AXFR und Neustart unverändert ausliefert.

Der Draft adressiert reale Reibung: Für jeden neuen RRTYPE müssen Masterfile-Parser und Provisionierung angepasst werden. Eine Stanza beschreibt Name, Nummer, Optionen und Felder. Daraus könnten Text–Wire-Konvertierung, Rückübersetzung und Formulare entstehen. Implementierung wird nicht abgeschafft, sondern teilweise in interpretierte Konfiguration verschoben.

Zwei Namen sind kein atomarer Stand

Definitionen sollen numerisch unter RRTYPE.ARPA und symbolisch unter RRNAME.ARPA als identische TXT liegen; ein CNAME ist möglich. Sprachpräfixe tragen Beschreibungen. Der Draft verlangt Gleichheit, definiert aber keinen Gewinner bei Abweichung. Caches, Sprachvarianten und Standardalias können verschiedene Generationen zeigen.

Auch das Verzeichnis ist im Text uneindeutig: Die Prosa nennt _LIST.RRTYPE.ARPA, das Beispiel _LIST.RRNAME.ARPA. Dies ist kein Freiraum für Produkterfindungen, sondern ein zu klärender Draft-Punkt.

TTL synchronisiert keine Flotte. RFC 8767 erlaubt unter begrenzten Fehlerbedingungen stale Antworten. Der Draft schreibt das nicht vor; ein Ausführungsbeleg muss dennoch aktuelle Autorität, gültigen Cache und stale Fallback unterscheiden. Die optionale lokale Override-Datei braucht ebenfalls Hash und Priorität.

DNSSEC authentifiziert keine Bedeutung

Der Sicherheitsteil nennt Spoofing und DNSSEC. Nach RFC 4033 liefert DNSSEC Ursprungsauthentisierung und Datenintegrität über Vertrauensanker und Authentisierungsketten. Es beweist nicht, dass Felder semantisch richtig, beide Kopien gleich, Längen sicher oder lokale Aktivierung gewollt sind.

Publikation, Authentisierung und Aktivierung sind getrennte Autoritätsakte. Ein korrekt signierter Fehler bleibt ein Fehler. Die Signatur darf deshalb nicht als Parser- oder Betriebsfreigabe verwendet werden.

X ist eine Schranke

X sagt, dass ein Typ zusätzliche Serverlogik benötigt. Ein Server ohne diese Logik soll einen Fehler melden. Die weiteren Buchstaben markieren Klassenbereich, veraltet oder experimentell. Sie beschreiben, sie implementieren nicht.

RFC 3597 ermöglicht unbekannte Typen bereits mit TYPEnn \# Länge Hex und verlangt transparente Behandlung ohne Additional-Section-Verarbeitung. Die neue Sprache verbessert Lesbarkeit, Formulare und tabellengesteuerte Konvertierung. Die generische Darstellung bleibt ein sicherer Rückzug, wenn freundliche Syntax nicht zugelassen werden kann.

Der Ausführungsbeleg

Der Draft warnt selbst vor ungültigen Definitionen, Parserfehlern und umgangenen Provisionierungsbeschränkungen. Darum gehören in den Beleg: Dokumentrevision; Verzeichnisantwort; Hashes der numerischen, symbolischen und sprachlichen RRsets; DNSSEC-Politik; TTL, Cachealter und stale; lokaler Override; Server-, Parser- und Backend-Build; Modul für jedes X; positive, negative und Ressourcen-Tests; Text–Wire–Text-Bytes; isolierter Zoneload; autoritative Abfrage; Aktivierungsumfang und Rollback.

Dieses Modell ist ein redaktioneller Vorschlag, keine Norm des Drafts. Seine Aufgabe ist Trennung: Signatur ist kein Test, Test kein Zoneload, Zoneload keine Antwort, eine Antwort keine Flottenkonvergenz.

Fehler werden dadurch zustellbar. Namensabweichung gehört zum Abgleich, unbekannter Token zur Fähigkeitszulassung, Byteabweichung zum Codec, Unterschied zwischen Canary und Produktion zum Deployment.

Die gemeinsame Schicht bleibt schmal

Gemeinsam sein müssen Grammatik, Name-Nummer-Bindung, Feldsemantik, Sprachregel, Registrierung und Interoperabilitätsinvarianten. Datenbank, Ressourcenlimits, Aktivierungszeit, Sonderlogik und Rollback bleiben bei der operativen Instanz.

Das folgt Heng Lus Prinzip der minimalen Anfangsspezifikation: Nur unvermeidbar Gemeinsames zentralisieren, spätere Entscheidungen lokalisieren und freiwillige Einführung durch laufenden Code belegen. Sichtbare lokale Experimente und RFC-3597-Fallbacks sind damit vereinbar; unsichtbare Versionsunterschiede sind es nicht.