Zusammenfassung

  • Revision 13 ist ein aktiver DNSOP Internet-Draft mit angestrebtem Best-Current-Practice-Status; sie ist weder RFC noch Implementierungsbeleg, und Datatracker verlangt eine überarbeitete Fassung.
  • Ein passender Unique Token an einem anwendungsspezifischen DNS-Namen kann Emission und Record-Auftreten kausal verbinden, beschreibt aber nicht automatisch Benutzer oder Berechtigungsumfang.
  • Benutzerkonto, Provider, Dienst, Domain, Owner-Name, Scope, Persistenz, Ablauf und Grant müssen denselben Transaktionsbezug behalten.
  • Dauerhafte Records, CNAME-Delegation und Update-Credentials dürfen Vertragsende oder Domaintransfer nicht lautlos überleben.

Der Resolver kennt kein Anwendungskonto

Domain Control Validation beantwortet eine begrenzte Frage: Kann ein Antragsteller einen providerseitig ausgegebenen Wert im relevanten DNS-Pfad erscheinen lassen? Dafür erzeugt der Dienst einen Unique Token, der Benutzer veröffentlicht ihn und der Validator sucht die Übereinstimmung.

Revision 13 von Domain Control Validation using DNS empfiehlt TXT-Records unter einem anwendungsspezifischen Underscore-Präfix. Der Token muss für die konkrete Domain ausgegeben worden sein. Seine Einzigartigkeit und bei Zufallswerten Unvorhersagbarkeit sollen Kollision und Erraten verhindern.

Der DNS-Answer enthält jedoch keine Identität aus der Provider-Datenbank. Er sagt nicht, welcher eingeloggte Benutzer den Challenge startete, welchem Mandanten die Domain zugeordnet werden soll oder welche Resource aktiviert wird.

Wenn der Transaktionsbezug verloren geht, kann ein richtiger Token dem falschen Konto gutgeschrieben werden. Der Validator hat seinen Teil erfüllt; das Gesamtsystem hat eine Identitätsbehauptung erfunden.

Drei Akteure teilen sich nicht automatisch eine Identität

Application User, DNS Administrator und Provider sind oft verschiedene Personen oder Systeme. Ein Intermediary kann als vierte Partei hinzukommen. Jeder authentisiert an einer anderen Oberfläche.

Ein Provider-Login beweist nicht, dass der User DNS-Änderungen anweisen darf. Ein DNS-Editor beweist nicht, dass er das Application Account besitzt. Eine Intermediary-Antwort beweist nicht, dass dessen Vertrag aktuell ist.

Der Receipt verbindet User-ID, Account, Challenge-ID, Domain, Owner-Name, Token-Digest, Provider, Service, angeforderten Scope, Ausgabe/Ablauf, DNS-Beobachtung, Policy-Version, Entscheidung und Grant-ID.

Fehlt ein Join, bleibt er unknown. Ein System darf ihn nicht aus zeitlicher Nähe, gemeinsamem Ticket oder derselben E-Mail-Domain ableiten.

Der Name des Records trägt Bedeutung

Ein spezifischer Label verhindert Hostname-Kollisionen und zeigt dem DNS Administrator, welcher Dienst die Bestätigung erwartet. Ein generischer Name lässt verschiedene Provider dieselbe Autorisierungsfläche nutzen.

Bei Service Confusion kann ein bösartiger Dienst den Challenge eines anderen Providers als eigenen Schritt darstellen. Der Administrator veröffentlicht den korrekten Wert; die Berechtigung entsteht beim anderen Dienst. Die Token-Prüfung ist korrekt, die Erklärung falsch.

Provider und Service müssen eindeutig sein. Verschiedene Privilege Scopes können verschiedene Namen benötigen. Öffentliche Dokumentation erklärt, was der Record freischaltet und wie lange.

Sensible Kontodaten gehören nicht ins DNS. Ein geschützter Authorization Record trägt Account, Resource und Scope und wird über Challenge-ID und Token-Digest angebunden.

Domain control ist kein Universalrecht

Dieselbe DNS-Fähigkeit kann Zertifikatsausstellung, Mail, Hosting, Custom Hostname, Social Identity oder zukünftige Validierungen erlauben. Die Folgen unterscheiden sich erheblich.

Bestehende Challenge-Schemata machen enge und breite Scopes nicht immer sichtbar. Ein Provider, der einen Match für mehrere Produkte nutzt, macht aus einem DNS-Beleg eine unsichtbare Sammelgenehmigung.

Vor der Veröffentlichung braucht der Administrator eine lesbare Erklärung: Provider, Service, Account, Domain, Resource, Scope, Persistenz, Ablauf und Widerruf. Seine Genehmigung gilt dieser Erklärung; der TXT belegt die DNS-Ausführung.

Neue Produktfunktionen dürfen den alten Verified State nicht stillschweigend übernehmen. Scope Expansion ist eine neue Autorisierungsentscheidung.

Mehrere TXT brauchen einen exakten Match-Receipt

Am selben Owner-Name können mehrere TXT stehen. Nach Anwendungsspezifikation reicht mindestens ein Match. Alte, fremde und aktuelle Tokens können gemeinsam geliefert werden.

„Gefunden“ ist kein Audit Record. Zu speichern sind exakte RDATA, ausgegebener Token, Zeitpunkt, TTL, CNAME-Kette und andere Values. Mehrere Character-Strings einer RDATA werden verkettet; der kanonische Vergleichswert zählt.

Abgelaufene Tokens sollten entfernt werden. Sie vergrößern Antworten, erschweren Untersuchungen und können in einem späteren Workflow fehlinterpretiert werden.

Unklare Löschverantwortung zeigt, dass auch die Berechtigungsbeziehung keinen eindeutigen Owner hat.

Ablauf hat mehrere Bedeutungen

One-off Records werden nach erfolgreicher Validierung meist nicht mehr gebraucht. Der Provider muss Token-Gültigkeit und sicheren Löschzeitpunkt nennen. expiry kann einen Timestamp oder never enthalten; die Policy kann auch out of band bleiben.

Token Acceptance, DNS TTL, Revalidation, Application Grant, Session, Update Credential und Ownership Epoch sind getrennte Uhren. Gelöschtes TXT widerruft nicht zwingend den Grant. Abgelaufener Token widerruft nicht die Fähigkeit, den nächsten zu beantworten.

Closeout prüft Token-Rejection, authoritative deletion, Cache-Fenster, gestoppte Revalidation, Credential Revocation und Grant Closure einzeln. expiry=never benötigt Owner, Begründung, Review-Date und Withdrawal-Test.

CNAME delegiert zukünftige Antworten

Delegated Validation kann einen Challenge-Namen auf einen Intermediary zeigen lassen. Eine dauerhafte Beziehung ermöglicht wiederkehrende one-off Prüfungen ohne manuelle DNS-Änderung.

Damit wird nicht nur ein Wert, sondern ein Prozess autorisiert. Das Register nennt Intermediary, finalen Provider, erlaubte Services und Domains, Accounts, Credentials, Laufzeit, Logs, Reviews und Exit.

Vertragskündigung, CNAME-Löschung, Account Closure und Grant Revocation sind unterschiedliche Aktionen. Ein Exit-Test gibt nach Widerruf einen neuen Challenge aus und zeigt, dass der alte Pfad ihn nicht mehr erfüllen kann.

Record Presence ist keine fortwährende Zustimmung. Mitarbeiterwechsel, Providerwechsel, Account Migration und Scope Expansion lösen erneute Genehmigung aus.

Domaintransfer eröffnet eine neue Identitätsepoche

Ein neuer Domaininhaber kann historische Records aus einem Backup wiederherstellen. Bei Persistent Validation könnte der Dienst daraus fortdauernden Zugriff des früheren Users ableiten.

Noch gefährlicher ist die automatische Reaktivierung früherer Ressourcen. Aktuelle Domainkontrolle beweist kein Recht an Nachrichten, Konfigurationen oder Secrets des Vorgängers.

Der Provider eröffnet einen neuen Ownership Epoch, erzeugt Token und Grant neu und isoliert historische Resources. Transfer oder Recovery braucht einen separaten Nachweis.

Eine legitime Übernahme kann Kontinuität herstellen. Sie bleibt eine ausdrückliche, protokollierte Entscheidung und nicht der Nebeneffekt eines TXT Match.

Public Suffix macht den Nenner sichtbar

Validierung eines Public Suffix könnte viele unabhängige Tenants betreffen. Der Draft empfiehlt grundsätzlich, ICANN Public Suffixes nicht als Ownership-Nachweis zu akzeptieren. Private Suffixes können zusätzliche Checks verlangen.

Ein Tenant, der ein Underscore-Kind anlegen kann, vertritt nicht automatisch den gesamten Suffix. Der Validator identifiziert registrable boundary, delegated zone und tatsächliche Update Authority.

Der DNS Record spricht für einen Node. Der Application Grant kann viele Namen erfassen. Diese Differenz gehört in die Scope-Entscheidung.

Sichere DNS-Beobachtung ersetzt keine Produktsemantik

Authoritative Queries, DNSSEC oder Resolver Controls können Vertrauen in die beobachtete Antwort stärken. Sie sagen nicht, welches Produkt und welcher Benutzer autorisiert wurden.

Umgekehrt rettet klare Dokumentation keinen Token, der für falsche Domain oder Transaktion akzeptiert wird. DNS Receipt und Authorization Receipt müssen beide passen und dieselben IDs teilen.

Query, CNAME, Owner, TTL, Zeit und Security Observation gehören in den DNS-Nachweis. Account, Resource, Scope, Grant und Ablauf gehören in den Anwendungsnachweis.

Ein grüner DNS-Nachweis lässt die Authorization Logic weiterlaufen. Er ist nicht die Authorization Logic.

Prozessstatus ist kein Deployment-Beleg

Am Freeze-Datum ist Revision 13 ein aktiver DNSOP Internet-Draft mit angestrebtem Best Current Practice. Der WG State verlangt wegen eines erhobenen Issues eine überarbeitete Fassung. Es gibt weder IESG Approval noch RFC.

Die Quellen belegen Text, Threat Model und Prozess. Sie belegen keine Implementierung, Adoption, echte Service Confusion, unberechtigte Zertifikatsausstellung, Account Takeover oder Incident.

Der Einstieg ist konstruiert. Zukünftige Revisionen können Requirements ändern. Systeme sollten Dokument- und Policy-Version statt eines zeitlosen Compliance Labels speichern.

Die Transaktion muss bis zum Grant reichen

Vor Ausgabe speichert man User, Account, Provider, Service, Domain, Boundary, Owner-Name, Scope, Persistence, Token-Digest und Ablauf. Bei Validierung kommen Response, Matching RDATA, CNAME, Resolver, DNSSEC Observation, Policy und Decision hinzu.

Beim Grant werden Resource, Effective Scope, Grant-ID, Revalidation Cadence, Removal Instruction und Credential verknüpft. Domain Transfer erzeugt neuen Epoch; Intermediary Delegation erneuert ihre Authority periodisch.

Korrekturen überschreiben den ersten Record nicht. Sie erzeugen nachvollziehbare Folgezustände. Service Outcome bleibt ein eigener Receipt.

Das Management darf „verified“ nicht überladen

Eine Kennzahl „Domains verified“ ist attraktiv. Ohne User-, Service- und Scope-Bindung misst sie jedoch technische Matches, nicht verantwortbare Autorisierungen.

Separate Metriken für challenge issued, token matched, grant created, authority renewed, domain transferred und authority revoked erhalten die Grenzen. Unknown Joins werden sichtbar.

Die schmale Aussage bleibt: Ein aktiver Challenge-Wert wurde am erwarteten DNS-Namen beobachtet. Benutzer, Privileg, Dauer, Persistenz und Ergebnis benötigen eigene Evidenz.

Quellen