Summary

  • The new DNS Filtering Transparency draft carries a database-operator identifier and incident identifier, not an authenticated account of why a filtering event occurred. It expressly allows the resolver to choose what to disclose and admits that a resolver can associate an experience with misleading information.
  • A second decision sits inside the consuming application. It keeps a local registry copy, chooses which database operators it is willing to support or trust, and decides whether the user sees a reference. A registered identifier supplies a resolution template; it does not certify the incident or the underlying policy.
  • The third decision belongs to the user because retrieving the incident page can reveal both an IP address and interest in a sensitive name. A defensible disclosure-chain receipt must therefore preserve resolver selection, application presentation and user retrieval as separate acts.

Imagine a browser showing this sentence after a failed lookup: the site was blocked by your DNS resolver because of a legal request, and further information is available at a link. The sentence appears singular. It has one cause, one actor and one destination. It feels more authoritative than an opaque error and more useful than a generic code.

Yet the sentence is the end of a small publishing system. Before it can appear, a resolver decides whether to attach one or more references to filtering databases. The application decides which database operators it recognises and whether to display any resulting reference. The user decides whether to retrieve the page, thereby exposing information that the DNS exchange itself had not necessarily disclosed to that database operator.

Those are not implementation details around one decision. They are three decisions with different controllers, evidence and incentives. Compressing them into “the DNS explained the block” would obscure who selected the account, who vouched for its presentation, and who accepted the privacy cost of opening it.

The draft carries a reference, not a verdict

draft-ietf-dnsop-filtering-transparency-00, posted on 1 August 2026, extends the Structured DNS Error work with a deliberately small abstraction. A filtered DNS response can contain an fdbs list. Each member pairs db, an identifier for an operator of a filtering-incident database, with id, an identifier for an entry in that database. Every pair in a list must concern the same underlying incident.

The application does not receive an arbitrary URL from the resolver. It looks up the database-operator identifier in a local copy of a proposed IANA registry, obtains a URI template, substitutes the incident identifier, and may then offer the expanded link. This reduces one obvious danger: an untrusted resolver cannot directly insert any link or prose it wants into a user interface merely by writing a URL into a DNS response.

That is a useful constraint. It is not authentication of the incident. The draft's security section says the mechanism does not prove that the filtering experience observed by the application is actually associated with the information presented. A party controlling the resolver could reuse an existing operator and incident identifier that expands to a real page while falsely associating that page with the user's lookup.

The distinction is fundamental. A dereferenceable record proves that a record exists at the resolved location. It does not prove that the resolver selected the correct record, that the database account is complete, that an order is valid, that the filter matched the intended target, or that the event occurred in the jurisdiction or at the time suggested by the page. The protocol transports a reference to an account. It does not turn that account into an adjudicated fact.

The draft is itself careful about authority. It is an active DNSOP Working Group Internet-Draft, not an RFC, and it currently lists no intended RFC status. Its mechanism can change. A governance record should state that status rather than quietly borrowing the authority of the RFC series for work still under discussion.

The resolver edits the disclosure set

The first control surface belongs to the resolver. The draft says there is no requirement to convey any particular information. A resolver chooses which database providers it supports and may use whatever mechanism it chooses to decide whether and when to include a reference.

That discretion makes the resolver an editor of the notice. It may include two databases, one database or none. It may attach an entry for one policy category but not another. It may be unable to map its internal event to an external incident database, or it may decide that disclosure would conflict with another obligation. None of these possibilities is automatically misconduct. They simply mean that the outgoing list is a selected set, not a complete census of explanations.

The negative inference therefore matters. No fdbs entry does not prove that no filtering occurred, that no incident page exists, that no legal or organisational instruction was involved, or that the resolver has no relevant record. It establishes only that this response, as received, did not provide a usable entry. Even the structured-error mechanism may be unavailable to some applications because host architecture does not expose the DNS response details they need.

A resolver-side receipt should capture the query and response time, the authenticated resolver relationship if one exists, the applicable Extended DNS Error code, the exact operator/incident pairs emitted, the policy or technical rule that selected them, and whether the selection process knew of alternatives it did not include. Sensitive details can be minimised or held under controlled access. What cannot be discarded is the fact that selection occurred.

The application edits what becomes visible

The second control surface sits in the browser, operating system or other consuming application. The draft does not require an application to trust every registered database operator. It expects implementations to maintain their own registry copy, support different sets of operators, and exercise judgment about which messages they display. Resolver identity, database-operator identity and local configuration may all shape that judgment.

This is not a small rendering choice. It determines which institutional account can reach a person. Two users receiving the same DNS response may see different explanations because their applications recognise different database IDs, use registry snapshots from different dates, apply different trust lists, or expose different DNS data from the host. One may see a link. The other may see only a failure. Neither screen alone reveals the whole upstream disclosure set.

Local registry state adds a temporal problem. The proposed database registry maps an operator ID to a URI template. Its contact may update that template at any time, while the draft warns operators to expect potentially long delays before applications update their copies. Reconstructing what a user could have seen therefore requires the registry snapshot used at that moment, not merely today's IANA entry or today's destination page.

The registration policy sharpens the boundary. The draft proposes first come, first served, with room for IANA to refuse deceptive or spurious registrations. RFC 8126 explains that first-come-first-served allocation normally performs no substantive review beyond checking form and uniqueness. Registration answers “which template belongs to this identifier?” It does not answer “is this operator's incident account accurate?” Applications still own the consequential decision to support, trust and surface it.

An application receipt should therefore record its registry-snapshot date or hash, the template actually expanded, the trust-list version, the resolver identity it associated with the response, the entries it accepted or suppressed, the reason class for that decision, and the text or affordance shown to the user. Without those fields, a screenshot of the final notice cannot explain whether missing context originated at the resolver, the local registry cache or the application's own policy.

The user's click is a disclosure decision

The third control surface appears after the notice is visible. Fetching the incident URL may tell the database operator the user's IP address and that someone at that address attempted to resolve a particular filtered name. For sensitive domains and restrictive environments, the explanatory act can create a second observation about the person seeking the explanation.

The draft responds with a strict boundary. If the application does not use a privacy-preserving mechanism such as a proxy, it must not retrieve the incident URL automatically without explicit user action. It also warns that a resolver and database operator acting together—or one party occupying both roles—could assign unique incident IDs and correlate activity across requests.

This turns “show more information” into a consent and routing decision. A client can display that a reference exists without fetching it. It can explain the likely destination and exposure. It can offer a proxied route where available. The user's choice should govern the network action, while the record should avoid becoming a new store of sensitive names and identities.

The receipt does not need to preserve the user's identity to prove that the boundary worked. It can record that no automatic fetch occurred, whether a direct or privacy-preserving path was offered, whether explicit action preceded retrieval, and the minimum telemetry necessary to audit the feature. Governance fails if the audit of privacy protection recreates the privacy harm through verbose logs.

Structured errors already reject automatic trust

The filtering-transparency proposal depends on the broader Structured Error Data for Filtered DNS draft. That work allows machine-readable explanation fields to be displayed, logged or otherwise used, but it also says the data must not be automatically trusted, displayed or allowed to influence security decisions without appropriate validation. It requires encrypted DNS transport for the structured exchange and limits third-party logging or transmission without the user's knowledge.

Those constraints expose a healthy separation. Structure makes information processable; it does not make it true. Encryption protects a path from passive observation; it does not establish that every statement supplied by the endpoint is correct. A registered JSON name stabilises syntax; it does not assign institutional authority. The new database reference adds another layer of context, but every layer retains its own evidentiary limit.

RFC 7754 provides the older architectural backdrop. It distinguishes the party that sets a blocking policy from the party that enforces it and notes that laws, regulation, operator rules and implementation can transform an original purpose at several stages. It regards prompt notice as valuable for correcting errors, while keeping legal and ethical judgments outside its technical analysis. The new draft improves the route to an explanation. It does not collapse those policy-setting and enforcement stages into a single actor.

A disclosure-chain receipt

A credible implementation should produce a compact disclosure-chain receipt with three linked sections.

The resolver section should identify the response observation, authenticated resolver context where available, EDE data, operator/incident pairs emitted, selection rule and known omission state. The application section should name the registry snapshot, resolved template, supported-operator and trust-policy versions, presentation decision and user-facing wording class. The user-action section should record whether retrieval was offered, whether explicit action preceded it, whether a proxy protected the request, and whether the fetch succeeded—without retaining the sensitive name or person beyond what the audit purpose requires.

The receipt must preserve uncertainty. If resolver identity is not authenticated, say so. If the application cannot access DNS response details, say so. If the registry copy is stale, record its date rather than silently substituting the current entry. If an incident page later changes, do not pretend the present page is the one the user was offered. If policy or order provenance is independently available, link it as separate evidence; do not infer it from the database identifier.

Such a receipt does not make filtering legitimate. It makes the disclosure path accountable. It allows an operator, application vendor, auditor or affected user to locate where an explanation disappeared, changed or exposed new information. Most importantly, it prevents the final screen from impersonating a consensus that no single participant actually made.

Sources