Zusammenfassung

  • draft-hoffman-duj-06 überträgt eine geordnete Liste manueller DNS-Hinzufügungen und -Löschungen als DUJS oder DUJ64; der Entwurf ist ausdrücklich weder Automatisierungsprotokoll noch kryptografischer Herkunftsnachweis.
  • Der Betreiber darf ein syntaktisch gültiges Paket aus lokaler Richtlinie ablehnen und muss die Zonenbefugnis des Nutzers prüfen. Atomarer Commit und sichtbare DNS-Wirkung bleiben weitere Nachweise.

Ein unbekannter Typ trifft eine bekannte Grenze

Ein Dienst verlangt einen neuen Ressourceneintrag. Der Typ steht noch nicht mit Namen im IANA-Register, lässt sich aber nach RFC 3597 als TYPE-Nummer und generische Datenfolge darstellen. Die DUJ-Zeichenkette ist formal korrekt. Der Parser versteht, wo Name, Typ und Daten liegen.

Der DNS-Betreiber lehnt sie ab.

Das ist kein Widerspruch. Revision 06 empfiehlt zwar, generische Typen verarbeiten zu können, lässt aber ausdrücklich eine lokale Richtlinie zu, die unbekannte Typen nicht hinzufügen oder löschen lässt. Darstellbarkeit ist eine Interoperabilitätseigenschaft. Zulässigkeit ist eine Entscheidung des Systems, das die Zone betreibt und die Folgen trägt.

Diese Trennung ist wichtiger als die JSON-Verpackung. Sie verhindert, dass ein gemeinsames Format zu einer tragbaren Befehlsgewalt wird.

Was die Verpackung tatsächlich festlegt

Ein DUJ ist ein JSON-Array mit genau zwei Werten. Zuerst steht DUJS oder DUJ64, danach ein nicht leeres Update-Array. Jede Aktionsvorlage enthält exakt add oder delete und eine Record-Data-Zeichenkette im Zonenformat von RFC 1035.

DUJS bleibt teilweise lesbar, verbietet jedoch Kommentare, Direktiven und eingebettete Zeilenumbrüche. DUJ64 codiert dieselben Daten als Base64. Dadurch werden schwierige Anführungszeichen und Escape-Sequenzen robuster transportiert, während der Inhalt für normale Nutzer absichtlich undurchsichtig wird. Die Aktion bleibt sichtbar.

Arrays statt erweiterbarer Objekte sollen Nebenbotschaften verhindern. Ein Dienst kann kein strukturelles Feld „dringende Sicherheitsaktualisierung“ hinzufügen, um die Entscheidung zu beeinflussen. Der Entwurf ist bewusst nicht erweiterbar; eine neue Semantik braucht einen neuen Anfangsbezeichner.

I-JSON beweist dabei keine Identität. Base64 verschlüsselt nicht. Ein registrierter oder generisch formulierter Typ erteilt keine Autorisierung.

Zwei Vertrauensbeziehungen mit einer manuellen Brücke

Der Dienst zeigt die Zeichenkette einem Menschen. Dieser meldet sich später beim DNS-Betreiber an und fügt sie ein. Der Entwurf begrenzt Herkunft und Integrität in beiden Abschnitten auf die jeweilige Verbindung.

Der Betreiber authentifiziert das Kundenkonto, nicht automatisch den erzeugenden Dienst. Der Dienst authentifiziert möglicherweise den Nutzer, aber nicht dessen Befugnis für jeden FQDN. Zwischen beiden können Zwischenablage, Ticketsystem oder Nachrichtendienst liegen. Ein Account für die Elternzone darf außerdem nicht zwangsläufig einen Namen unterhalb eines delegierten Zonenschnitts ändern.

Darum gehören Herkunft des angezeigten Pakets, exakter Hash, authentifiziertes Konto, Account-zu-Zone-Berechtigung und Richtlinienentscheidung in getrennte Datensätze. Ein Sammelstatus „verifiziert“ würde die eigentliche Autoritätszuordnung unsichtbar machen.

Atomar heißt vollständig, nicht berechtigt

Der Betreiber muss vor der Ausführung prüfen, ob das gesamte geordnete Update atomar auf die Zielzone angewandt werden kann. Verhindert eine Aktion den vollständigen Commit, darf keine Teilmenge verarbeitet werden. Das schützt vor einem Zustand, in dem ein alter Wert gelöscht, sein Ersatz aber nicht installiert wurde.

Ein schlechtes Paket kann dennoch vollständig sein. Ein Angreifer kann konsistente Aktionen formulieren. Eine veraltete Anweisung kann ohne Fehler committen. Ein Paket für den falschen Kunden kann exakt das tun, was darin steht.

Deshalb folgt auf die Syntaxprüfung die lokale Prüfung: Ist der Nutzer zur Änderung der genannten Zone berechtigt? Existiert bei delete exakt der Datensatz? Fehlt er bei add exakt? Liegt der Name diesseits des Zonenschnitts? Erlaubt die Richtlinie den Typ? Der Betreiber kann jedes DUJ ablehnen, etwa wenn es denselben Datensatz erst hinzufügt und dann löscht, und sollte die Begründung anzeigen.

Die gemeinsame Spezifikation bleibt minimal; die spätere Entscheidung bleibt lokal.

Ein Commit braucht einen präzisen Beleg

Wiederholungen führen zu erlaubten Auslassungen. Ein add kann übersprungen werden, wenn der identische Datensatz bereits existiert; ein delete, wenn er bereits fehlt. Revision 06 empfiehlt, den Nutzer über jede vorgenommene Änderung zu informieren.

Für verantwortliche Automatisierung reicht „angenommen“ nicht. Ein Änderungsbeleg sollte Paket-Hash, Konto, Zone, Berechtigungsgrundlage, lokale Entscheidung, RRsets vorher und nachher, übersprungene Aktionen, Transaktionskennung und Zeitpunkt verbinden. Das ist eine operative Empfehlung dieses Artikels, keine bestehende Normforderung.

Auch der Commit ist nicht die letzte Wirklichkeitsschicht. Autoritative Server können später laden, Secondaries nachlaufen und rekursive Resolver alte Daten bis zum TTL-Ende liefern. Ein Zertifikats- oder Maildienst kann aus einer anderen Sicht fragen. Autorisierung, atomarer Commit, autoritative Beobachtung und nachgelagerte Akzeptanz brauchen deshalb eigene Belege.

Status ohne Aufwertung

Revision 06 wurde am 26. September 2026 eingereicht und läuft am 30. März 2027 ab. Datatracker führt sie als aktiven individuellen Internet-Draft ohne RFC-Stream und ohne formalen Stand im IETF-Standardprozess. Die Standards-Track-Absicht im Text ist weder WG-Annahme noch IETF-Konsens, Genehmigung oder RFC.

Der eingefrorene Unterschied zu Revision 05 betrifft nur Nummer und Daten. Die Quellen belegen keine Implementierung, Interoperabilität, Verbreitung, Messung, Sicherheitsstörung oder geschäftliche Wirkung.

Quellen