Zusammenfassung

  • DNSOP eröffnete am 24. August 2026 den Working Group Last Call für draft-ietf-dnsop-integration-04 und nannte den 7. September als Enddatum. Im gesicherten Datatracker-Stand heißt es weiterhin In WG Last Call; ein verabschiedeter RFC liegt nicht vor.
  • Der Entwurf verlangt mehr als eine anfängliche Kontrolle. Ablauf, Änderung des DNSSEC-Status, Entfernung des erwarteten Resource Records und Resynchronisierung gehören zum Lebenszyklus.
  • Ein knapper Konformitätstest umfasst vier Übergänge: Einrichten, Aktualisieren, Löschen sowie Übertragen oder Neuregistrieren. Für jeden braucht es Auslöser, Prüfer, Zielzustand und eine Obergrenze für veraltete Daten.
  • AT-Protocol-Handles werden beidseitig geprüft und periodisch neu aufgelöst. Im ENS-Beispiel des Entwurfs kann die Entfernung eines DNS-Eintrags dagegen keinen älteren positiven On-Chain-Claim widerrufen, solange dieser Pfad keine negativen NSEC-Beweise verarbeitet.
  • Die Vier-Übergänge-Matrix ist ein Analysevorschlag von Daniel Kade, keine vom IETF angenommene Vorgabe. Sie macht unterschiedliche Architekturen anhand ihrer Ergebnisse vergleichbar.

Ein Fristende ist noch kein Konsens

Die DNSOP-Vorsitzenden eröffneten den Last Call am 24. August und baten bis zum 7. September um Unterstützung oder Einwände. Eine Erinnerung vom 6. September wies auf den folgenden Tag als Frist hin. Belegt ist damit ein Verfahrensdatum, nicht das Ergebnis der Meinungsbildung.

Der IETF Datatracker führt Version 04 als Internet-Draft mit beabsichtigtem Status Informational. Die Arbeitsgruppe steht auf In WG Last Call, der IESG-Eintrag auf I-D Exists. Weder RFC-Status noch Annahme oder ein sicherer nächster Schritt lassen sich daraus ableiten.

Gerade bei einem Text über aktuellen Zustand wäre eine andere Darstellung widersprüchlich. Was an einem bestimmten Tag galt, darf weder im DNS noch in der Berichterstattung ungeprüft fortgeschrieben werden.

Mit dem Namen übernimmt die Anwendung seinen Lebenszyklus

Version 04 des Entwurfs nennt Ablauf, DNSSEC-Statuswechsel und das Entfernen eines erwarteten Records als Ereignisse, auf die eine Integration reagieren muss. Andernfalls könnte ein früherer Domaininhaber innerhalb der Anwendung Kontrolle behalten, obwohl sich die Grundlage im DNS geändert hat.

Beim Einrichten soll nur der aktuelle Registrant oder eine autorisierte Partei den Bezug herstellen können. Technisch geeignete Namen sollen nicht durch eine willkürliche Liste bevorzugter TLDs ausgeschlossen werden. Und die Implementierung soll erklären, wie ihr Zustand wieder mit dem globalen DNS abgeglichen wird.

Permanentes Prüfen ist keine neutrale Lösung. Abfragen kosten Ressourcen, Caches gehören zum Betrieb, vorübergehende Ausfälle können falsche Negative erzeugen und hohe Frequenzen an Grenzen stoßen. Die Architektur wählt daher ein Aktualisierungsbudget. Verantwortlich wird sie, wenn sie dessen Folgen offenlegt.

Der hier vorgeschlagene Test ordnet diese Folgen in vier Zeilen:

Übergang Beweisfrage Sichtbares Ergebnis
Einrichten Was belegt aktuelle Domainkontrolle oder wirksame Delegation? Die neue Bindung wird angenommen oder abgelehnt.
Aktualisieren Welche neuere Aussage verdrängt die alte? Ziel oder Kennung wechselt.
Löschen Wie wird Abwesenheit zum Signal, und wann? Die Bindung wird ungültig, leer oder ausdrücklich veraltet.
Übertragen oder neu registrieren Wie beseitigt der neue Registrant den alten Zustand? Frühere Anwendungsautorität endet; neue beginnt mit aktuellem Nachweis.

Zusätzlich sind Auslöser, Prüfinstanz, Cache-Regel, maximale Abweichung und manuelle Wiederherstellung zu nennen. DNSOP hat diese Tabelle nicht verabschiedet. Sie übersetzt die vorhandenen Abschnitte zu Lebenszyklus, Kontrolle, Vollständigkeit und Synchronisierung in einen reproduzierbaren Versuch.

AT Protocol kennt einen ungültigen Zustand

AT Protocol trennt die relativ beständige DID von einem veränderbaren, lesbaren Domain-Handle. Die Handle-Spezifikation verlangt Prüfung in beide Richtungen: Das Handle muss zur DID auflösen, und das DID-Dokument muss auf dasselbe Handle zurückverweisen. Eine einseitig veröffentlichte Fremdzuordnung wird dadurch nicht automatisch vertrauenswürdig.

Löst ein bekanntes Handle nach bestätigter Prüfung nicht mehr auf, soll es als ungültig markiert werden. Dienste dürfen Ergebnisse zwischenspeichern, sollen aber periodisch neu auflösen. DNS-Änderungen müssen keinen eigenen Anwendungs-Event auslösen; die nächste Prüfung macht die Entfernung sichtbar.

Die Frist bleibt eine Abwägung. Ein langer Cache spart Last und hält falsche Anzeigen länger fest. Häufiges Auflösen verkürzt die Abweichung, erhöht aber Verkehr und Empfindlichkeit für vorübergehende Störungen. Entscheidend ist, dass ein negativer Zielzustand und ein Pfad dorthin existieren.

Die Spezifikation sagt zudem, dass DNSSEC für diese Handle-Auflösung nicht erforderlich ist. Der DNSOP-Entwurf ist somit kein allgemeines DNSSEC-Gebot. Gemeinsam ist den Systemen die Pflicht, ihren Autoritäts- und Aktualisierungspfad zu erklären.

Im ENS-Beispiel ersetzt ein Positivbeweis nur einen anderen

Der für ENS beschriebene Weg bringt einen positiven DNSSEC-Beweis auf die Blockchain. Ein jüngerer positiver Beweis kann einen älteren überschreiben. Wechselt die Kontrolle über den Namen, kann der neue Registrant mit dem eigenen Record die Integration neu herstellen.

Ohne neuen positiven Beweis bleibt jedoch eine Lücke. Laut Entwurf unterstützt ENS in diesem Pfad derzeit keine negativen NSEC-Beweise. Die Nichtexistenz oder Entfernung des Records lässt sich damit nicht on-chain belegen. Der alte positive Claim besteht fort, bis ein neuer positiver ihn ersetzt; das bloße Löschen des DNS-Records oder der Ablauf des Namens widerruft ihn nicht.

Diese Aussage entstand nicht erst in Version 04. Sie steht bereits in Version 03, wie der Vergleich beider Fassungen zeigt. Das Änderungsprotokoll der Version 04 spricht von überarbeitetem Vollständigkeitstext.

Die ENS-Anleitung zum DNS-Import beschreibt, wie ein neuer Inhaber _ens ändert und per Aktualisierungsfunktion den neuen Zustand einliest. Das liefert einen jüngeren positiven Beleg. Es belegt nicht, dass das Löschen allein den alten Zustand automatisch entfernt.

Der Befund darf nicht auf alle ENS-Funktionen oder DNS-Integrationen ausgedehnt werden. Er betrifft einen bestimmten Nachweispfad. Seine allgemeine Prüffrage ist dennoch belastbar: Wie erfährt ein System, das positive Aussagen aufnehmen kann, dass eine solche Aussage nicht mehr existiert?

Für den bequemen Eingang zahlt oft der spätere Inhaber

Einrichtung unterstützt Wachstum und lässt sich als Erfolg demonstrieren. Löschen erfordert Abfragen, Verifikation, Zustandswechsel, Support und je nach Architektur eine Transaktion. Ohne unlautere Absicht kann so eine ausführliche Einrichtungsanleitung neben einem unbestimmten Ausgang entstehen.

Die Auswirkung hängt von der Funktion ab. Ein altes Pseudonym täuscht, ein altes Ziel fehlleitet, eine für Zahlung oder Administration verwendete Bindung bewahrt Macht. Eine Prüfung muss daher den Anwendungszustand betrachten, nicht nur die Erreichbarkeit eines DNS-Records.

Auch Domainablauf ist kein überall identischer Moment. Der gTLD-Lebenszyklus der ICANN kennt mehrere Phasen. Statt einer erfundenen Einheitsfrist braucht jede Anwendung eine Regel, welches Ereignis wann ihren Zustand ändert.

Heng Lus Modell einer minimalen Anfangsspezifikation mit späteren lokalen Entscheidungen passt dazu: Die vier Übergänge bilden den gemeinsamen Kern; Resolver, Beweise, Cache und Wiederherstellung bleiben lokale Wahl.

Wenn laufender Code der Primärbeleg ist, zählt ein Label wie „DNS-verifiziert“ weniger als ein Test, der den Record setzt, ändert, löscht und den Namen neu registriert. Erst dann wird sichtbar, wo Autorität tatsächlich endet.

Quellen

  1. DNSOP Working Group Last Call
  2. Erinnerung an den DNSOP Last Call
  3. IETF-Datatracker-Eintrag
  4. Dokumenthistorie im IETF
  5. DNS-Integrationsentwurf, Version 04
  6. DNS-Integrationsentwurf, Version 03
  7. Offizieller Vergleich der Versionen 03 und 04
  8. DNSSEC-Protokolländerungen, RFC 4035
  9. AT-Protocol-Handle-Spezifikation
  10. AT-Protocol-Repository-Synchronisierung
  11. ENS-Anleitung zum On-Chain-DNS-Import
  12. gTLD-Lebenszyklus der ICANN
  13. Heng Lu — Minimale Anfangsspezifikation und lokale Folgeentscheidungen
  14. Heng Lu — Laufender Code als Primärbeleg