Summary

  • Revision 27 of the IETF draft for Structured Error Data for Filtered DNS is in the RFC Editor Queue. It lets clients request an I-JSON explanation inside Extended DNS Error data, but it is not yet a numbered RFC and its final code points remain unassigned.
  • An authenticated encrypted resolver connection protects one hop. It does not prove the upstream policy author, legal mandate, classification accuracy or correct remedy. Display, trust, challenge and final application treatment remain separate local decisions.

A clear explanation can still carry the wrong authority

The opening is a constructed operating scenario, not a reported incident. Its purpose is to separate legibility from mandate. A resolver can return a correctly formed explanation, over a channel whose endpoint identity and integrity are valid, while the explanation itself reflects a classification made elsewhere. The packet can be authentic as a statement by the selected resolver without making every proposition inside it true.

That distinction is timely. The IETF Datatracker lists draft-ietf-dnsop-structured-dns-error-27, dated 30 July 2026 and last updated on 19 August, in the RFC Editor Queue. Its intended status is Proposed Standard, and the RFC Editor is awaiting editor assignment. The draft is therefore advanced work, but not a numbered RFC. It still carries placeholders for the future RFC number and IANA-assigned values. Operators should not turn a queue state into a claim that final code points, universal support or deployed behavior already exist.

The proposal updates the diagnostic model of RFC 8914. Extended DNS Errors can already say that a response was blocked, filtered, censored or forged. They are useful, but their free-form extra text was designed for human diagnostics rather than reliable automated parsing. Revision 27 adds a zero-length Structured DNS Error option in the client query. Its presence says the client understands an I-JSON object in the EDE EXTRA-TEXT field.

The shared structure is deliberately small. A contact field can point toward the team that receives misclassification reports. A justification field can offer human-readable context. A sub-error field can carry a registry-defined integer. An organization field can name the party represented by the explanation, and a language field can tell the client how to present the human text. None of those fields is a signature over institutional authority. Structure makes a claim easier to parse; it does not make the claim self-authorizing.

The client asked for a format, not a policy

When a supporting client sends the SDE option, it requests structured handling if the server filters the answer. The option has no data of its own. It does not announce agreement with filtering, consent to a particular policy, or willingness to click, call, bypass or block. Local policy may instruct the client not to send it at all.

The server still controls the filtering response. It may return an empty answer, NXDOMAIN or, less ideally, a forged address. If it returns one of the relevant EDE codes, it should add structured detail unless configured otherwise. The draft distinguishes a policy imposed by the local network operator from one determined by the DNS operator. It also proposes a still-unassigned error for a forwarder reporting that an upstream DNS server imposed the block.

Those distinctions improve evidence. They do not establish the legal or contractual source of a policy. “Network operator policy” describes a protocol category. It does not show which corporate officer approved a rule, whether an employer's acceptable-use policy applies to this device, whether a court order covers this name, whether a parent configured a home filter, or whether a security supplier made a mistaken reputation decision. The registry can standardize the label without adjudicating its mandate.

The same restraint applies to a sub-error. An enumerated value is safer to process than free-form prose because clients know its syntax and scope. Registration, however, says what the value means on the wire. It does not prove that a domain actually contains malware, that a phishing classification is current, or that every application should produce the same consequence. The difference between a controlled vocabulary and a verified fact must remain visible.

Encryption protects the last hop, not the whole claim chain

The draft requires clients to act on structured extra text only when the DNS response is integrity-protected. An unencrypted answer can be modified by an on-path attacker. Even an encrypted channel without resolver authentication is insufficient for the contact, justification and organization fields, because those free-form values can redirect user behavior. In that case, the client must ignore them, although it may still process the enumerated sub-error.

An authenticated DoT, DoH or DoQ connection is stronger. It protects confidentiality and integrity and verifies the selected resolver endpoint. That is an important property, but a bounded one. It means the client received these bytes from the resolver identity it chose. It does not prove that an upstream resolver originated the same bytes, that an intermediate forwarder preserved them, or that the named organization is the accountable policy principal.

Extended DNS Error information is hop-by-hop. A resolver may originate the explanation, forward an upstream explanation, omit some fields or construct a new one. The draft makes forwarding behavior implementation-dependent and subject to operator policy. The final client-resolver hop can therefore be perfectly protected while an earlier hop was unauthenticated, or while the final resolver recast the upstream message into its own words.

That is not a defect in encryption. It is a provenance boundary. Transport authentication answers who controlled one endpoint and whether the message changed on that connection. It does not automatically serialize the complete institutional chain behind a decision. Operators that need stronger evidence must retain resolver configuration, upstream identity, forwarding mode, policy version, classification source, timestamps and correction history outside the packet.

Legacy forwarders make the boundary sharper. A proxy unaware of EDE semantics may relay attacker-controlled extra text. The draft suggests accepting EDE only from explicitly configured DNS servers or using resolver information to improve identification. That is an operational trust decision, not a property created by the JSON braces.

Free-form help can become a second attack surface

The contact and justification fields exist to help users challenge mistakes. They can also be used to manipulate them. A malicious encrypted resolver could offer a support route controlled by an attacker, invent an organization name or supply prose that pressures the user to disclose personal data or install unwanted software.

For that reason, the draft gives the client security policy real authority. Contact information should be displayed only when the resolver has sufficient reputation under administrative configuration or a built-in trust list. Human justification is never an input to automated enforcement or DNS protocol behavior. Organization text must be rendered as plain text, not active markup, and it must not be displayed unless it matches a trusted registered name or survives appropriate heuristics.

The design refuses to specify how an organization trust list is built and updated. That omission is honest. A universal protocol registry cannot know every employer, school, household, ISP, public authority and security provider that may have a legitimate local role. Nor can it decide which of them may bind a specific user. The client or accountable administrator must maintain that mapping and bear the consequences of showing it.

Automatic connections are especially dangerous. A client must not initiate network requests merely because a contact-like value appeared in error text. Restricting initial contact schemes to non-HTTP forms reduces silent reporting, reflection and entrapment risks, but it does not make every human interaction safe. The safest UI can show a resolver identity, a controlled error description and an independently configured support route while keeping unverified free text out of the primary decision surface.

A short TTL is a correction opportunity, not a correction proof

Filtering classifications change. The draft allows short TTLs, such as ten seconds, so a corrected category or reputation decision can propagate quickly. Longer values may reduce query load when updates are less frequent. This is a useful operational trade-off, but TTL expiry does not guarantee that every cache, forwarder or upstream classifier changed its view.

Leadership should separate the clocks. One clock belongs to the DNS answer cache. Another belongs to the classification feed. A third belongs to policy approval. A fourth measures the complaint and allowlisting process. A fifth records when clients actually observe the change. A ten-second TTL cannot compensate for an upstream list that refreshes hourly, a forwarder that recreates explanations, or a support queue that takes days.

Evidence for correction should include the queried name and type, resolver identity, EDE and sub-error, policy source if known, answer and negative-cache TTLs, upstream response state, classification version, complaint receipt, decision owner and the first successful post-correction observation. Without that chain, “the block was removed” may mean only that one resolver answered differently once.

Privacy needs its own clock and owner. Structured error text may reveal the filtering organization, its internal policy and the domain a user tried to reach. The draft says clients must not log or transmit those contents to third parties without the user's knowledge. An observability program that exports every error to a remote analytics service can destroy the privacy gain of encrypted DNS while claiming to measure transparency.

Explanation is evidence, not the final command

Once a client has authenticated the resolver and validated what it is safe to process, it still has choices. It may display a bounded explanation, log it locally, direct the user to an independently configured support desk, retry after expiry, use a permitted alternative resolver, stop the application action, or preserve evidence for review. Those consequences differ across a managed enterprise, a household, a public network and a safety-critical device.

The narrow common layer should make the event legible: which resolver returned which controlled code, which optional fields were present, which language was requested and which transport property protected the hop. It should not silently convert a resolver's statement into a legal judgment or an irreversible local action.

That is the useful governance lesson. Standardize the minimum evidence envelope. Keep the registries precise. Authenticate the transport that actually carries the claim. Then preserve the distinction between protocol meaning, policy authorship, institutional mandate, factual classification and final treatment. When those authorities collapse into one green status, a clearer error message merely gives an unsupported decision a better interface.

Sources