Zusammenfassung

  • Der Entwurf transportiert nur Betreiber- und Vorfalls-ID; die Anwendung löst sie mit einer lokalen Registerkopie auf und entscheidet selbst, welchen Datenbanken sie vertraut.
  • Ein erreichbarer Eintrag authentifiziert nicht, dass genau dieser Vorfall die beobachtete DNS-Antwort verursacht hat. Ein kontrollierter Resolver kann eine bestehende ID in falschem Kontext wiederverwenden.

Die Datenbankseite existierte, beschrieb eine echte gerichtliche Sperre und war über eine registrierte Vorlage erreichbar. Nur der aktuelle Nutzer hatte diese Sperre nie erlebt. Sein Resolver hatte den alten Eintrag an einen anderen Namensfehler gehängt.

Alle Adressen waren korrekt. Die Kausalbehauptung war falsch.

draft-ietf-dnsop-filtering-transparency-00 will politische Eingriffe von technischen DNS-Störungen unterscheidbar machen. Dazu begrenzt es den Resolver auf Referenzen, statt beliebige Links oder öffentliche Texte in eine Anwendung einzuspeisen.

Revision 00 vom 1. August 2026 ist ein aktiver DNSOP Working Group Internet-Draft mit beabsichtigtem Standards-Track-Status und läuft am 2. Februar 2027 ab. Sie ist kein RFC, kein eingerichtetes IANA-Register, keine Browserregel und kein Implementierungsnachweis. Auch die abhängige Structured-DNS-Error-Spezifikation ist noch Arbeit im Gang.

Zwei Kennungen sind eine Behauptung

Ein Eintrag kombiniert db, die Kennung eines Filterdatenbankbetreibers, und id, die Kennung eines Vorfalls. Eine fdbs-Liste kann mehrere Einträge tragen, die sich auf denselben zugrunde liegenden Vorfall beziehen müssen.

Der Resolver wählt die Einträge. Die Anwendung hält eine lokale Kopie des vorgeschlagenen Registers und findet dort eine URI-Vorlage der Stufe 1 oder 2. Sie setzt die Vorfalls-ID ein und entscheidet anschließend, ob sie den Betreiber unterstützt und den Link anbietet.

Diese Umleitung verhindert, dass ein automatisch konfigurierter Resolver jede beliebige Phishing-Adresse in die Fehleroberfläche schreibt. Sie bindet die Aussage aber nicht an die beobachtete Antwort.

Der Resolver behauptet Relevanz, das Register liefert Routing und die Datenbank veröffentlicht Inhalt. Jede Stufe hat einen anderen Autor.

Erfolgreiches Laden beweist nur Erreichbarkeit

Der Entwurf sagt ausdrücklich, dass er die Zuordnung zwischen erlebtem Filterereignis und angezeigter Information nicht authentifiziert. Ein Angreifer mit Kontrolle über den Resolver kann einen Vorfall behaupten, der nicht stattgefunden hat.

Er muss ein Paar wiederverwenden, das zu einer abrufbaren URL führt. Das begrenzt die Auswahl, ersetzt aber keine Signatur. Eine wahre Seite kann als Erklärung für die falsche Anfrage dienen.

HTTP 200 bestätigt einen Serverpfad. Ein professioneller Text bestätigt, dass jemand eine Darstellung veröffentlicht hat. Beides beweist weder den rechtlichen Auftrag noch dessen Anwendung auf die aktuelle Abfrage.

Oberflächen müssen deshalb „vom Resolver gemeldet“, „Betreiber lokal akzeptiert“, „Seite geladen“ und „Vorfall authentifiziert“ auseinanderhalten. Der letzte Zustand liegt außerhalb dieses Mechanismus.

Das Register ist kein Gütesiegel

Das vorgeschlagene Register enthält Name, Kontakt, Betreiber-ID und Auflösungsvorlage. First come, first served soll die Vergabe steuern; IANA könnte täuschende oder vorgeschobene Anträge ablehnen.

Das koordiniert Namen. Es bewertet nicht Beweismethode, Unabhängigkeit, Rechtskompetenz, Berichtigungsverfahren oder Aufbewahrung. Ein Eintrag verpflichtet keine Anwendung zur Anzeige.

Anwendungen brauchen eine eigene Vertrauensliste. Sie können Resolveridentität, Betreiber und lokale Konfiguration einbeziehen. Registriert bedeutet zuordenbar, nicht akkreditiert.

Die lokale Kopie darf nicht für jeden Vorfall live bei IANA abgefragt werden. Das schützt vor einem zentralen Beobachtungspunkt, erzeugt aber Versionsunterschiede. Vorlagen können geändert werden, während Clients alte Ziele behalten.

Eine reproduzierbare Prüfung speichert daher den Hash der verwendeten Registerkopie.

Der Erklärungsabruf ist ein neues Datenschutzereignis

Beim Abruf kann die Datenbank die IP-Adresse des Nutzers und dessen Interesse an einer gefilterten Domain erfahren. In manchen Rechtsordnungen ist diese Verbindung selbst riskant.

Auch ein vertrauenswürdiger Betreiber beseitigt Beobachter auf dem Weg nicht. Ziel, Zeitpunkt, Pfad oder eindeutige ID können den Vorfall verraten. Ein Datenschutz-Proxy reduziert direkte Offenlegung, wird aber zum neuen Protokollführer.

Ohne solchen Schutz darf eine Anwendung die Seite nicht vor einer ausdrücklichen Nutzerhandlung automatisch laden. Vorschau, Sicherheitsprüfung, Reputationstest, Preconnect und Metadatenabruf gehören zu derselben Grenze.

Linkkonstruktion, Anzeige, Aktivierung, Proxywahl, Anfrage, Weiterleitung und Antwort brauchen getrennte Belege.

Eindeutige IDs erlauben Korrelation

Eine Vorfalls-ID darf anfragespezifisch sein. Resolver und Datenbank können dann gemeinsam beobachten, welches im DNS ausgegebene Token später im Web auftaucht. Ein Unternehmen kann beide Rollen besitzen.

Das Vertrauen des Nutzers in den Betreiber beweist nicht, dass IDs grob oder kurzlebig sind. Anwendungen sollten erkennen, ob Kennungen pro Vorfall, Domain, Netz, Client oder Anfrage vergeben werden.

Ein Proxy löscht das Token nicht. Er verschiebt möglicherweise nur die Stelle, an der Adresse, Zeit und Ziel zusammenlaufen.

Der Host kann die Referenz verwerfen

Manche Betriebssysteme geben detaillierte DNS-Antworten nicht an Anwendungen weiter. Der Resolver sendet fdbs, der Host liefert einen allgemeinen Fehler und der Browser sieht nichts.

Ausgabe, Empfang, Hostfreigabe, Parsing, Registererkennung, Vertrauensentscheidung, Anzeige, Klick und Abruf sind einzelne Übergänge. Fehlende Seitenaufrufe beweisen keine fehlende Resolverausgabe.

Jeder Übergang braucht seinen eigenen Nenner. Eine Endquote ohne Zwischenverluste macht Architekturgrenzen zu vermeintlichem Nutzerverhalten.

Mehrere Quellen sind keine Abstimmung

Mehrere Einträge können die Kompatibilität erhöhen, aber bei Datum, Grundlage oder verantwortlicher Stelle widersprechen. „Derselbe Vorfall“ ist zunächst die Aussage des Resolvers.

Die Anwendung kann Unterschiede mit Herkunft zeigen oder nach klarer lokaler Regel priorisieren. Sie sollte sie nicht zu einer quellenlosen offiziellen Begründung verschmelzen.

Übereinstimmung ist ebenfalls kein automatischer Beweis, wenn Datenbanken dieselbe Quelle kopieren. Anzahl ersetzt keine Provenienz.

Transparenz braucht begrenzte Versprechen

Die Stärke des Entwurfs liegt in der Machtteilung: Resolver referenziert, Register routet, Anwendung vertraut und Nutzer ruft ab. Bequeme Implementierung darf diese Grenzen nicht wieder zusammenziehen.

Automatisches Vertrauen in jeden Registereintrag, Hintergrundabruf und ein Label „verifiziert“ würden Koordination in Autorität verwandeln.

Der Nutzer soll erfahren können, dass eine Richtlinie eingegriffen hat. Er soll nicht gezwungen werden, eine unbelegte Kausalität zu glauben oder durch den Erklärungsabruf eine zweite sensible Spur zu erzeugen.

Quellen