**Session Date/Time:** 18 Feb 2026 20:00

# [DNSOP](../wg/dnsop.html)

## Summary

This interim meeting focused on two drafts: `draft-ietf-dnsop-structured-error` (Structured DNS Error) and `draft-nottingham-public-resolver-errors` (DNS Filtering Details for Applications).

The authors of `structured-error` presented the changes made in response to IETF Last Call feedback. The chairs indicated a strong preference for another Working Group Last Call (WGLC) for this draft to ensure broad consensus before proceeding to the IESG.

Mark Nottingham presented `public-resolver-errors`, detailing a shift in its approach to leverage external filtering incident databases. Implementation progress in Chrome was shared. Key discussions revolved around privacy implications of interacting with these databases and the utility of an IANA registry for them.

The working group indicated interest in pursuing `public-resolver-errors` for adoption.

## Key Discussion Points

*   **Structured DNS Error (draft-ietf-dnsop-structured-error)**:
    *   Dan Wing presented version -16, highlighting changes made in response to IETF Last Call feedback.
    *   Key updates include:
        *   Relaxed language regarding client processing of extended error data, allowing clients full flexibility ("do whatever it wants"). This was confirmed as an intentional design choice.
        *   The request indicator for extended error data was moved to a new, dedicated EDNS(0) option code to improve clarity.
        *   Sub-error codes (enums) can now be returned in any response, and a new IANA registry has been created for them.
*   **DNS Filtering Details for Applications (draft-nottingham-public-resolver-errors)**:
    *   Mark Nottingham introduced the problem: DNS-based censorship is often indistinguishable from technical errors, leading to poor user experience and support load. The draft aims to provide end-users with more clarity.
    *   The draft's approach has evolved from identifying trusted resolvers to utilizing filtering incident databases (e.g., Lumen Database), which any resolver can point to. Applications retain the right to decide which databases they trust.
    *   David Literati (Chrome) provided an implementation update, confirming work is underway to land this functionality in Chrome M147 (early April release), initially behind a feature flag, to link to the Lumen Database from DNS error pages.
    *   **Privacy Concerns**: Gautam Akiwate (Apple) raised significant concerns about user privacy, specifically how users can connect to filtering databases without leaking information about the sites they were visiting. Gautam offered to collaborate on text to address this.
    *   **IANA Registry Debate**: Paul Hoffman expressed reservations about establishing a "first come, first serve" IANA registry for censorship-related databases, arguing it might create unnecessary work for IANA without providing substantial value, as browser vendors will likely trust specific providers regardless. Mark Nottingham responded that the registry could offer transparency regarding which databases browsers consult and did not anticipate a flood of registrations.
    *   **URI Permanence and Coordination**: Dan Wing inquired about the coordination required between DNS ID values and external databases to ensure URI permanence for incident descriptions. Mark Nottingham clarified that registration implies coordination with database operators and a policy for stable URL templates. External databases provide richer context (e.g., legal documents) that cannot be directly conveyed via DNS.
    *   **Dependency on Structured DNS Error**: The draft utilizes the EDNS option code from `structured-error` for signaling. While convenient, Mark noted it would be "pretty trivial" to adapt if `structured-error` did not advance, though it would require more DNS infrastructure.
*   **Draft Compatibility**: Mark Nottingham affirmed that there are no known incompatibilities between `draft-ietf-dnsop-structured-error` and `draft-nottingham-public-resolver-errors`, with the latter building upon the mechanisms of the former.
*   **Procedural Discussion**: A discussion took place regarding the need for another Working Group Last Call for `draft-ietf-dnsop-structured-error` after it had already undergone an IETF Last Call. The chairs emphasized the significant technical changes made and the desire for a renewed consensus signal from the working group to strengthen its position for the IESG.

## Decisions and Action Items

*   **Decision**: `draft-ietf-dnsop-structured-error` will undergo another Working Group Last Call (WGLC) to reaffirm consensus within the DNSOP WG following the incorporation of feedback from its IETF Last Call.
*   **Action Item (Chairs)**: Benno Overijnder will confirm with the Area Director the procedural aspects of conducting a WGLC after an IETF Last Call.

## Next Steps

*   **For `draft-ietf-dnsop-structured-error`**: The chairs will initiate a new Working Group Last Call after this interim meeting.
*   **For `draft-nottingham-public-resolver-errors`**:
    *   Mark Nottingham will present the updated version (`-02`) at IETF 125.
    *   Following the IETF 125 presentation and any further working group feedback, a call for adoption will be initiated on the DNSOP mailing list to gauge consensus for the working group to adopt and progress the document.
    *   The authors are encouraged to address the privacy concerns raised during the discussion, potentially by incorporating new text.
    *   The draft name ("public resolver errors") is misleading and should be updated to reflect its broader applicability beyond just public resolvers.
*   **General**: Brief meeting minutes, highlighting key decisions and action items, will be circulated to the DNSOP mailing list.