Summary

  • A resolver can return a registered database identifier and a valid incident identifier, and the resulting page can load successfully, without authenticating that the filtering event occurred or caused the user's DNS result.
  • The proposed design limits the resolver to abstract identifiers, leaving template lookup and database trust with the application; privacy requires a separate choice because following the link can disclose both the user and the sensitive domain.

The DNS lookup failed. The resolver supplied a database name and an incident code. The browser expanded them through a known template, fetched a professional-looking page and showed a detailed account of a legal block.

There had been no legal block. The resolver controlled the first claim and had reused a real page.

That fracture is the reason draft-ietf-dnsop-filtering-transparency-00 is more careful than its product name sounds. It does not make DNS filtering transparent by letting a resolver write a message into the browser. It narrows what the resolver can contribute to two identifiers, then gives the consuming application the consequential decisions: which database operators it recognises, which it trusts, whether it presents an action and how the action is retrieved.

Revision 00 is an active DNSOP Working Group Internet-Draft dated 1 August 2026 and expiring 2 February 2027. It is intended Standards Track, but it is not an RFC, a completed IANA registry, a browser policy or a deployment report. Its fdbs field depends on the still-evolving structured DNS error draft. The architecture should therefore be read as a proposed division of authority, not an installed public service.

The resolver supplies a reference, not a destination

The draft defines a DNS Filtering Database Entry with two fields. db names the operator of a database that records filtering incidents. id identifies an entry in that database. Several entries can be carried in an fdbs array, and every entry in one list must relate to the same underlying incident.

This indirection is deliberate. A resolver is often selected automatically by a network the user did not choose. DNS responses can also arrive from an untrusted party. If either could inject an arbitrary URL or unrestricted public message into application chrome, a coffee-shop resolver could turn a failure page into a phishing surface.

Instead, the application keeps a local copy of a proposed DNS Filtering Database Registry. A registry row maps an operator ID to a Level 1 or Level 2 URI template. The application inserts the incident ID, obtains a URI, and can decide whether to offer it to the user.

The registry is not consulted over the network for every error. That rule removes a live lookup from the critical path and lets the application inspect its copy. It also creates version state. The registry contact can change a template, while browsers, operating systems and other clients may update days or months later. “The registry says” is incomplete unless the claim identifies which snapshot the application used.

Successful routing is not authenticated causality

The draft says plainly that it does not authenticate the association between the incident experienced by an application and the information presented. An attacker controlling a resolver can claim that filtering is taking place when it is not.

The attack is constrained but not eliminated. The attacker needs an operator ID and incident ID that expand to a URL which can be dereferenced. That is more work than writing an arbitrary URL, yet it does not transform the result into proof. A page can exist. The page can be controlled by a reputable database. The page can even describe a real filtering event. None of those facts proves that the user's query encountered that event.

The evidence chain has at least three authors. The resolver asserts that a pair is relevant. The registry routes the pair to a template. The database publishes a record. Causal truth would require evidence binding the observed DNS result to the record, not merely agreement among addressable strings.

This distinction matters operationally. A support system that closes a case when the incident page returns HTTP 200 has verified availability of an explanation service, not correctness of the explanation. A compliance report that counts fdbs references has measured resolver assertions, not legal orders. A browser badge that reads “verified block” would overstate the mechanism.

Registration is coordination, not accreditation

The proposed registry would use a first-come, first-served policy, while allowing IANA to refuse entries it considers deceptive or spurious. Each row would contain the database name, contact, operator ID and resolution template.

That is a thin coordination surface. It prevents two operators from casually claiming the same identifier and gives applications a stable place to obtain templates. It does not evaluate editorial practice, evidentiary standards, jurisdictional expertise, retention policy, correction procedure or political independence.

Applications therefore still need their own trust policy. One may support only a small set of databases. Another may let an institution configure the set. A third may recognise an operator but decline to show it when the resolver is unknown. The resolver sends a list precisely because different applications will support different operators.

An IANA row cannot be used to bypass that local judgment. Nor should an application's trust in an operator be projected onto every record that operator hosts. Institutional reputation and event-level proof are different layers.

The explanation fetch can disclose the event again

The most sensitive act may happen after DNS resolution. Dereferencing the incident URI can reveal the user's IP address to the database operator along with the fact that the user tried to resolve a particular filtered or censored domain. In some jurisdictions, that association can create more risk than the generic DNS error the user first saw.

Even a trusted database does not eliminate the network trace. An observer may infer the category or exact incident from the destination, path, timing or a unique identifier. A privacy-preserving proxy can separate the user's address from the database request, but the proxy then becomes another custody point with its own logs, policy and failure modes.

For that reason the draft draws a hard operational line: when no such proxy is used, an application must not automatically fetch the incident URI without explicit user action.

That rule reaches beyond obvious page loads. Link previews, safe-browsing inspection, speculative navigation, screenshot generation, metadata unfurling and background availability checks can all dereference a URI before a person clicks it. A product that says “we did not display the page” may still have crossed the privacy boundary through an automated helper.

The receipt must therefore distinguish link construction, presentation, user activation, proxy choice, outbound request and database response. A single “explanation shown” event cannot demonstrate that the user controlled the disclosure.

One identifier can become a cross-request beacon

The id field may describe a request-specific incident, but it does not have to. Flexibility helps databases organise records. It also gives the identifier cardinality and reuse policy security significance.

A resolver and database operator acting together can issue unique IDs and watch which ones are later fetched. The same risk exists when one party operates both roles. A token presented as an explanation reference becomes a correlation handle linking the DNS event to a subsequent web request.

User choice about trusted database operators can reduce exposure. It cannot prove that a chosen operator avoids unique identifiers, short retention or linkage with resolver logs. Applications need to know whether IDs are shared across an incident, per domain, per network, per client or per query. The draft warns about collusion; product policy must turn that warning into observable limits.

Proxying changes the correlation shape, not the identifier itself. A database can still observe which token was requested, while a proxy can observe timing and destination. Batching, caching or anonymising retrieval may help, but each technique changes freshness and error handling. There is no privacy-free transparency channel.

Emission may never reach the application

The mechanism is also intentionally described as unreliable. Many applications do not receive the details of DNS responses from their host environment. A resolver can send a structured error correctly, an operating system can reduce it to a generic lookup failure, and the browser can have nothing to interpret.

This produces a longer chain than most dashboards will show: the resolver selected an entry; the DNS response reached the device; the host exposed structured error data; the application parsed fdbs; its registry copy recognised the operator; policy accepted it; a link was presented; the user acted; retrieval completed; the database supplied useful context.

Failure at one stage cannot be assigned backward without evidence. A database with no page views cannot conclude resolvers sent nothing. A resolver that emitted entries cannot claim users were informed. A browser that supports the registry cannot assume its operating system exposes the option. An operator that sees clicks measures only the subset willing and able to disclose them.

That is not a defect to conceal with one completion percentage. It is a reason to keep stage-specific receipts and publish the denominator at each transition.

Multiple databases do not reconcile truth

An fdbs list can carry several entries for the same underlying incident. That improves the chance that an application recognises at least one operator. It can also expose disagreements in dates, legal basis, affected names or the entity that requested filtering.

The list requirement creates common subject matter, not common conclusions. Applications should not collapse several records into one authoritative narrative merely because they arrived in the same DNS response. The resolver chose the list, each database controls its record, and the user agent controls presentation.

If sources disagree, the application may show that uncertainty, prefer one operator under local policy, or decline to synthesise. What it should not do is convert plurality into a majority vote about whether the event occurred. Availability of claims and verification of claims remain separate.

Transparency needs a chain of bounded promises

The design's strongest property is not the future registry. It is the refusal to give one actor the whole path. The resolver cannot choose an arbitrary destination. The registry does not force an application to trust a database. The application cannot make the resolver's incident claim authentic by rendering it. The user can decline the privacy-bearing fetch.

That separation is valuable only if implementations preserve it. Shipping an embedded allowlist with no update provenance, prefetching every recognised entry, labelling registry membership as verification, or merging resolver assertion and database record into one audit event would rebuild the centralised authority the draft avoids.

DNS filtering transparency should tell a user more than “the network broke.” It should not answer that confusion by manufacturing certainty. The public promise is narrower: a resolver can offer a bounded reference; an application can decide whether the reference is safe and useful; the user can decide whether to disclose the follow-up request. Proof of the incident remains a separate job.

Sources