Zusammenfassung

  • Der Entwurf DNS Filtering Transparency transportiert eine Kennung des Datenbankbetreibers und eine Vorfallskennung. Das Wertepaar verweist auf einen Eintrag, authentisiert aber weder dessen Zuordnung zum erlebten Filtervorgang noch verpflichtet es den Resolver zu einer bestimmten Offenlegung.
  • Eine Anwendung hält eine lokale Kopie des vorgeschlagenen Registers, entscheidet über unterstützte oder vertrauenswürdige Betreiber und darüber, ob ein Verweis sichtbar wird. Die Registrierung ordnet einer Kennung eine URI-Vorlage zu; sie beglaubigt nicht den Vorfall oder die zugrunde liegende Maßnahme.
  • Der Abruf kann IP-Adresse und Interesse an einem sensiblen Namen offenlegen. Deshalb bildet die ausdrückliche Nutzerhandlung eine dritte Entscheidung, die im Nachweis von Resolverausgabe und Anwendungsdarstellung getrennt bleiben muss.

Aus Sicht des Nutzers wäre das Ergebnis erfreulich klar: Nicht ein gewöhnlicher technischer Fehler, sondern DNS-Filterung verhinderte die Auflösung; weitere Angaben sind über einen Link erreichbar. Eine solche Meldung kann Fehlzuordnungen korrigierbar machen und einen undurchsichtigen Eingriff von einer Störung unterscheiden.

Die sichtbare Aussage stammt dennoch nicht unmittelbar aus einem einzigen Ereignis. Ein Resolver wählt externe Datensätze aus. Browser, Betriebssystem oder eine andere konsumierende Anwendung bestimmen, welche Betreiber sie anerkennen und welchen Hinweis sie zeigen. Erst danach entscheidet ein Mensch, ob er eine neue Verbindung zum Datenbankbetreiber auslöst.

Diese drei Stellen besitzen unterschiedliche Informationen, Vollmachten und Anreize. Ein Screenshot des Endzustands macht aus ihren Entscheidungen scheinbar eine einheitliche Erklärung. Er zeigt weder unterdrückte Alternativen noch den Zustand des lokalen Registers noch den aus Datenschutzgründen unterlassenen Abruf.

Ein Verweis ist kein beglaubigter Befund

draft-ietf-dnsop-filtering-transparency-00 wurde am 1. August 2026 als erste Arbeitsgruppenversion veröffentlicht. Der Entwurf ergänzt strukturierte DNS-Fehler um die Liste fdbs. Jedes Element enthält db für den Betreiber einer Filtervorfallsdatenbank und id für einen bestimmten Eintrag. Mehrere Elemente einer Liste müssen demselben zugrunde liegenden Vorfall zugeordnet sein.

Der Resolver darf nicht einfach eine beliebige URL oder frei formulierte Botschaft in die Oberfläche einbringen. Die Anwendung sucht db in ihrer lokalen Kopie eines vorgeschlagenen IANA-Registers, liest eine URI-Vorlage der Stufe 1 oder 2 und setzt id ein. Das erschwert es einem unbekannten Netzwerkresolver, die Vertrauenswirkung des Browsers für beliebige Ziele zu nutzen.

Die formale Beschränkung beweist aber nicht, dass der richtige Eintrag gewählt wurde. Der Sicherheitsabschnitt hält ausdrücklich fest, dass der Mechanismus die Verbindung zwischen dem von der Anwendung erfahrenen Filtervorfall und den dargestellten Angaben nicht authentisiert. Wer einen Resolver kontrolliert, kann ein wirklich vorhandenes, auflösbares Kennungspaar wiederverwenden und einer unpassenden Anfrage zuordnen.

Eine erreichbare Seite belegt daher nur die Erreichbarkeit dieser Ressource. Sie belegt weder eine Verfügung noch deren Zuständigkeit, zeitliche Geltung, räumlichen Umfang oder korrekte technische Umsetzung. Sie beweist auch nicht, dass der Datensatz vollständig, unverändert oder für genau diesen Nutzer maßgeblich ist. Das Protokoll liefert eine prüfbare Spur, keine abgeschlossene Beweisführung.

Auch der Dokumentstatus verlangt Präzision. Die Version 00 ist ein aktiver DNSOP-Arbeitsgruppenentwurf, der einen früheren Individualentwurf ersetzt. Sie ist kein RFC und nennt derzeit keinen angestrebten RFC-Status. Das Verfahren darf als ernsthafter Vorschlag analysiert werden, ohne ihm vorzeitig normative Endgültigkeit zuzuschreiben.

Der Resolver bestimmt die erste Auswahl

Der Entwurf verlangt nicht, dass ein Resolver eine bestimmte Information übermittelt. Er entscheidet, welche Datenbankanbieter er unterstützt, und kann nach eigenen Verfahren festlegen, ob und wann er einen Eintrag mitsendet. Die ausgegebene Liste ist somit ein kuratierter Ausschnitt.

Für einen Vorgang können mehrere öffentliche Quellen existieren, von denen nur eine unterstützt wird. Eine interne Regel kann noch keiner externen Vorfallsnummer entsprechen. Offenlegungspflichten können sich bei Sicherheitsfiltern, Jugendschutz, Unternehmensregeln und behördlichen Vorgaben unterscheiden. Keine dieser Möglichkeiten beweist Fehlverhalten. Sie verhindert jedoch, dass die Antwort als vollständiges Verzeichnis behandelt wird.

Fehlt fdbs, ist nur nachgewiesen, dass die beobachtete Antwort keinen nutzbaren Datenbankverweis enthielt. Daraus folgt weder das Fehlen einer Filterung noch das Fehlen einer Anordnung, eines Vorgangs oder eines Korrekturwegs. Manche Hostarchitekturen geben DNS-Antwortdetails zudem nicht an alle Anwendungen weiter, sodass eine gesendete Angabe vor der Oberfläche verschwinden kann.

Ein Resolverbeleg sollte Zeitpunkt, authentisierten Dienstkontext soweit vorhanden, EDE-Code, ausgegebene Kennungspaare, Auswahlregel und bekannte nicht ausgegebene Alternativen festhalten. Sensible Namen und Personenbezug gehören minimiert und geschützt. Die Tatsache, dass eine Auswahl stattgefunden hat, darf bei dieser Minimierung jedoch nicht verloren gehen.

Die Anwendung entscheidet über die Verteilung

Die zweite Kontrollfläche liegt im Client. Der Entwurf geht davon aus, dass Anwendungen unterschiedliche Mengen von Datenbankbetreibern unterstützen. Sie müssen urteilen, wessen Fehlermeldungen sie anzeigen. Identität des Resolvers, Identität des Datenbankbetreibers und lokale Konfiguration können die Entscheidung beeinflussen.

Zwei Geräte mit derselben DNS-Antwort können deshalb verschiedene Hinweise erzeugen. Eines kennt db und bietet den Link an, das andere besitzt noch keinen Eintrag. Eines akzeptiert die Angabe nur von einem ausdrücklich konfigurierten Resolver, das andere prüft zusätzlich eine Vertrauensliste. Ein Betriebssystem reicht die strukturierten Felder an den Browser weiter, ein anderes nicht.

Aus der Endansicht ist die Ursache der Abweichung nicht erkennbar. Ein fehlender Link kann auf den Resolver, einen alten Registerstand, eine Vertrauensentscheidung oder die Hostarchitektur zurückgehen. Ein sichtbarer Link beweist umgekehrt nur, dass die Anwendung ihn verteilt hat — nicht, dass sie die hinterlegte Begründung oder Anordnung bestätigt hat.

Das lokale Register führt eine Zeitdimension ein. Der Kontakt eines Eintrags kann die URI-Vorlage jederzeit ändern; zugleich warnt der Entwurf vor potenziell langen Verzögerungen, bis Anwendungen ihre Kopien erneuern. Wer den damaligen Zielort rekonstruieren will, braucht den damaligen lokalen Stand. Der heutige IANA-Eintrag kann die frühere Auflösung nicht ersetzen.

Registrierung ist außerdem keine Güteprüfung. Vorgesehen ist „First Come First Served“, wobei IANA irreführende oder substanzlose Anträge ablehnen darf. RFC 8126 beschreibt diese Zuteilung als Verfahren ohne inhaltliche Prüfung jenseits von Form und Eindeutigkeit. Das Register klärt, welche Vorlage zu einer Kennung gehört; die Anwendung bleibt für Vertrauen und Anzeige verantwortlich.

Der Anwendungsbeleg sollte deshalb Datum oder Hash des Registerstands, die tatsächlich expandierte Vorlage, Versionen von Unterstützungs- und Vertrauenslisten, angenommene und verworfene Einträge, eine Grundklasse und die dargestellte Meldungsform enthalten. Sonst erscheint ein lokales Cacheproblem als Schweigen des Resolvers oder ein kaputter alter Pfad als fehlender Vorfall.

Der Abruf der Erklärung erzeugt neue Daten

Die Vorfallsdetails befinden sich nicht in der DNS-Nachricht. Beim Öffnen verbindet sich die Anwendung mit dem Datenbankbetreiber. Dieser kann die IP-Adresse sehen und erfahren, dass von dort ein gefilterter Name aufgelöst werden sollte. Bei sensiblen Themen kann schon die Suche nach einer Begründung ein zusätzliches Risiko darstellen.

Der Entwurf zieht deshalb eine klare Grenze. Ohne datenschutzwahrenden Vermittler wie einen Proxy darf die Anwendung die Vorfallsseite nicht automatisch und ohne ausdrückliche Nutzerhandlung abrufen. Er warnt auch vor der Möglichkeit, dass Resolver und Datenbankbetreiber zusammenarbeiten oder dieselbe Partei sind und eindeutige Vorfallskennungen zur Korrelation einsetzen.

Eine Oberfläche kann zunächst nur die Existenz zusätzlicher Informationen anzeigen. Sie kann Empfänger und Expositionsart erklären, direkten und geschützten Weg unterscheiden und die Verbindung erst nach der Entscheidung aufbauen. Der Compliance-Nachweis muss daraus kein neues Verzeichnis sensibler Nutzerabfragen machen. Er kann auf die Reihenfolge, den Wegtyp und den technischen Ausgang beschränkt bleiben.

Diese Sparsamkeit ist Bestandteil der Governance. Ein System, das Transparenz über einen Eingriff schaffen soll, darf nicht nebenbei eine dauerhafte Beobachtungsquelle über Menschen errichten, die nach dessen Begründung fragen.

Struktur, Verschlüsselung und Register leisten Verschiedenes

Der neue Entwurf baut auf Structured Error Data for Filtered DNS auf. Dieses Vorhaben macht Felder maschinenlesbar, verlangt aber, dass sie ohne angemessene Validierung weder automatisch vertraut noch angezeigt oder für Sicherheitsentscheidungen genutzt werden. Für den strukturierten Austausch ist verschlüsselter DNS-Transport vorgesehen.

Maschinenlesbarkeit schafft Verarbeitbarkeit, nicht Wahrheit. Verschlüsselung schützt den Übertragungsweg vor passiver Beobachtung, nicht vor einer unzutreffenden Aussage des Endpunkts. Ein registrierter JSON-Name oder Betreiberbezeichner stabilisiert Syntax und Zuordnung, überträgt jedoch keine institutionelle Entscheidungsmacht.

RFC 7754 ergänzt diese Schichten um die politische Vorgeschichte. Wer eine Sperrpolitik festlegt, ist oft nicht dieselbe Stelle, die sie durchsetzt. Gesetz, Verwaltungsregel, Betreiberpolitik, Architektur und Implementierung übersetzen den ursprünglichen Zweck mehrfach und können dabei Nebenwirkungen erzeugen. Eine schnelle Mitteilung fördert Abhilfe, entscheidet aber nicht über Rechtmäßigkeit oder Ethik einer konkreten Maßnahme.

Der Nachweis der Offenlegungskette

Daniel Kade schlägt einen dreiteiligen Nachweis vor. Der Resolverteil bewahrt Beobachtung, Authentisierungsstatus, EDE, ausgegebene Paare, Auswahlregel und bekannte Auslassungen. Der Anwendungsteil fixiert Registerstand, verwendete Vorlage, Unterstützungs- und Vertrauenspolitik, Darstellungsentscheidung und Meldungsklasse. Der Nutzerteil hält nur fest, ob ein Abruf angeboten wurde, ob eine ausdrückliche Handlung vorausging, ob ein Proxy schützte und wie der Abruf ausging.

Unbekanntes bleibt unbekannt. Eine nicht authentisierte Resolveridentität wird nicht nachträglich ergänzt. Für eine nicht erklärte Auslassung wird kein Motiv erfunden. Ein alter Registerstand wird nicht durch den heutigen ersetzt. Eine später veränderte Seite wird nicht als damaliger Inhalt ausgegeben. Unabhängig belegte Anordnungen oder Regeln werden als eigene Quellen mit eigener Provenienz verknüpft, niemals aus db und id abgeleitet.

Der Nachweis legitimiert keine Filterung. Er macht den Weg der Erklärung verantwortlich. Mit ihm lässt sich bestimmen, an welcher Stelle Kontext verloren ging, warum eine Anwendung ihn nicht verteilte und welche zusätzliche Offenlegung sein Abruf verlangt hätte. Eine übersichtliche Meldung kann dann nicht länger einen gemeinsamen Beschluss vortäuschen, den die drei Beteiligten nie gefasst haben.

Quellen