**Session Date/Time:** 16 Mar 2026 03:30 # [DNSOP](../wg/dnsop.html) ## Summary The DNSOP Working Group met at IETF 125 to discuss the status of active drafts and several new proposals for consideration. Key topics included the automation of delegation management via DDNS, updates to DNS data ranking rules, operational guidelines for protective DNS (PDNS) providers, and the mitigation of amplification risks associated with large records on wildcard owner names. Several documents are nearing completion, while others require further community feedback or alignment with emerging protocols like DELEG. ## Key Discussion Points ### Working Group Status and Administration * **Chairs:** Benoit Andrew, Andre Lomonosov * **Secretaries:** Shumon Huque, Peter Thomassen * **Area Director:** Matt Lepinski * **Note Taker:** Paul Hoffman * **Document Updates:** * Three RFCs published in the last four months (Wes Hardaker et al.). * `draft-ietf-dnsop-ds-automation` has reached consensus; awaiting Shepherd write-up. * The Working Group Last Call (WGLC) for `draft-ietf-dnsop-structured-dns-error` has been extended until early next week to allow for more community feedback following updates from the February interim meeting. * `draft-ietf-dnsop-ns-revalidation` is awaiting author responses to WGLC feedback. * `draft-ietf-dnsop-domain-verification-techniques` is considered nearly ready for WGLC following the addition of threat models and multi-account support. * New adoptions include `draft-ietf-dnsop-delext`, `draft-ietf-dnsop-rfc9364bis`, and `draft-ietf-dnsop-dry-run-dnssec`. ### Delegation Management via DDNS **Presenter:** Johan Stenstam **Slides:** [Delegation Mgmt via DDNS](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-delegation-mgmt-via-ddns-00) **Draft:** [draft-ietf-dnsop-delegation-mgmt-via-ddns](https://datatracker.ietf.org/meeting/125/id/draft-ietf-dnsop-delegation-mgmt-via-ddns.html) * The draft proposes a "push" model for automated delegation management where the child zone updates the parent via signed dynamic updates (DDNS) rather than the "pull" model used by scanners. * The child discovers the update target via the DSYNC record and uses SVCB parameters to determine supported bootstrapping mechanisms. * **Discussion:** Peter Thomassen raised a point regarding how the child authenticates an unsigned parent. Johan Stenstam clarified that methods similar to RFC 867 (multi-vantage point) or using signed provider zones (RFC 9615) are supported. The authors aim for technical completeness soon, focusing next on editorial refinements. ### Clarifications to the DNS Ranking Data **Presenter:** Willem Toorop **Slides:** [Clarifications to the DNS Ranking Data](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-clarifications-to-the-dns-ranking-data-00) * This proposal seeks to update Section 5.4.1 of RFC 2181, which the authors argue is outdated as it assumes a monolithic database where data is merged regardless of source. * The proposal introduces directives to ensure authoritative servers do not merge zone data and that recursive resolvers only accept specific, relevant data from authoritative responses. * **Discussion:** Jim Reid supported the work but requested stronger guidelines for recursive resolvers. Andre Lomonosov (speaking as an implementer) cautioned against "must" requirements for resolvers returning additional data from cache. There was a discussion on whether to wait for the DELEG working group's output; Jim Reid advocated for moving forward immediately. ### Considerations for Protective DNS Server Operators **Presenter:** Mingxuan Liu **Slides:** [Considerations for Protective DNS Server Operators](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-considerations-for-protective-dns-server-operators-00) * The presentation outlined operational and security considerations for PDNS providers, including blocklist selection, rewriting policies, and performance impacts. * **Discussion:** Andre Lomonosov suggested this work might be better suited for DNS-OARC best practices rather than an RFC. Stéphane Bortzmeyer expressed concerns regarding the "Protective DNS" terminology and the potential for these techniques to be used for censorship. Ben Schwartz noted that the current draft conflicts with existing specifications (e.g., Extended DNS Errors, DNSSEC) and unlikely to reach IETF-wide consensus. Vittorio Bertola and Gianpaolo Fasoli suggested focusing on transparency and informational tracks. ### Avoid Large Records with Wildcard Owner Names **Presenter:** Bashan Zhou (on behalf of Peng Zhou) **Slides:** [avoid-large-wildcard-records](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-sessb-avoid-large-wildcard-records-00) * The draft addresses amplification risks where large TXT records are placed under wildcard names, allowing attackers to bypass caches and trigger large responses. * The authors suggest hosting providers should set limits on record sizes under wildcards or return truncated/smaller responses. * **Discussion:** Andre Lomonosov suggested folding this into other work on DNS limits. Warren Kumari and Johan Stenstam argued in favor of short, operational RFCs that address specific "bad ideas" quickly, expressing a desire for the IETF to process such simple guidance with higher velocity. ## Decisions and Action Items * **WGLC Extension:** The WGLC for `draft-ietf-dnsop-structured-dns-error` is extended for one week. * **Mailing List Discussion:** The chairs called for more feedback on `draft-ietf-dnsop-integration` and the new proposals for Ranking Data and Wildcard records. ## Next Steps * **Side Meeting:** Post-Quantum DNSSEC side meeting scheduled for Tuesday morning (Chaired by Peter Thomassen). * **Ops Area Meeting:** Discussion on DNS workload management within the IETF (presented by Wes Hardaker) to take place Monday afternoon. * **Session II:** DNSOP Session II is scheduled for Thursday. --- **Session Date/Time:** 19 Mar 2026 08:30 # [DNSOP](../wg/dnsop.html) ## Summary The DNSOP Working Group met for its second session to discuss various proposals regarding root zone distribution, error transparency for filtered DNS, and protocol ordering. The session also included a "DNS Dispatch" function to evaluate whether new work items regarding Dynamic DNS and AI Discovery belong within DNSOP or elsewhere. ## Key Discussion Points ### Root Zone Distribution: Root Cache and Local Root Paul Hoffman presented [Root Cache](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-sessb-chairs-slides-session-i-00) (as an update to RFC 8806), followed by Wes Hardaker presenting [Local Root](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-sessb-chairs-slides-session-i-00). * **Technical Approach:** Both proposals aim to modernize RFC 8806 using ZoneMD and DNSSEC validation. Paul’s "Root Cache" focuses on "cache stuffing" (treating the zone as if queries were already made), while Wes’s "Local Root" allows for either authoritative-like behavior or cache filling. * **Motivations:** Paul argued for operational safety in failure cases (falling back to normal DNS), while Wes emphasized reducing dependency on the Root Server System (RSS) infrastructure. * **Concerns:** * **Ossification:** Dwayne Wessels expressed concern that widespread deployment might hinder the evolution of the root zone (e.g., deployment of `draft-ietf-dnsop-delext` or DELEG). * **Sustainability:** Ray Bellis (RSO) questioned the claim that the current RSS model is unsustainable, stating RSOs do not currently see scalability issues. * **Problem Statement:** Joe Abley, Jim Reid, and Robert (Rob) requested a clearer problem statement, questioning if the privacy and reliability benefits justify the effort. * **HTTP Review:** Mark Nottingham suggested an early review from the HTTP Directorate due to the use of HTTPS for zone fetching. ### DNS Filtering Transparency Mark Nottingham presented [Considerations for Protective DNS Server Operators](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-considerations-for-protective-dns-server-operators-00), discussing `draft-nottingham-dnsop-dns-filtering-transparency`. * **Pivot in Design:** The draft has moved away from registering individual resolvers to registering "Filtering Incident Databases" (e.g., Lumen). This mitigates the risk of privileging specific resolvers. * **Implementation:** The draft layers on [draft-ietf-dnsop-structured-dns-error](https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/). Chrome has a preliminary implementation behind a flag. * **Discussion:** Support for the transparency goals was voiced by Vittorio Bertola, Ralf Weber, and Giampaolo Scalone, particularly for legally mandated filtering (e.g., Italy’s Piracy Shield). Robert cautioned that such mechanisms could be abused to broadcast "censorship" messages for non-compliance with laws (e.g., GDPR geofencing). ### Ordering of RRsets in DNS Message Sections Joe Abley presented [Clarifications to the DNS Ranking Data](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-clarifications-to-the-dns-ranking-data-00), referencing `draft-abley-dnsop-rrset-ordering`. * **Problem:** In January 2024, a change in RRset packing on Cloudflare’s 1.1.1.1 caused failures in glibc and Cisco switches because the CNAME was not ordered before the target record in the answer section. * **Proposed Fix:** A narrow clarification that CNAME and DNAME processing must result in an ordered list in the response. * **Discussion:** Stuart Cheshire noted that while this fix is pragmatic for old devices, client implementations should still be made more robust. André Surikov (Chair) questioned if a full rewrite of RFC 1034/1035 might be better than "bug-fix" RFCs. ### DNS Dispatch: Dynamic DNS Update Protocol Joe Abley presented on behalf of Andrea regarding [Delegation Mgmt via DDNS](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-delegation-mgmt-via-ddns-00). * **Proposal:** Standardize the "DynDNS2" protocol (a common REST-like HTTP update method) to replace the 25+ variations used by CPE devices. * **Discussion:** Stuart Cheshire argued that standard DNS Update (RFC 2136) is more efficient and already exists. Ralf Weber and Peter Thomassen suggested this is an application-layer issue, not for DNSOP. Ted Hardie suggested a BoF in Vienna to see if implementers would actually converge on a single standard. ### DNS Dispatch: AI Discovery using DNS Nick Williams presented a proposal for [AI Discovery using DNS](https://datatracker.ietf.org/meeting/125/materials/slides-125-dnsop-sessb-chairs-slides-session-i-00). * **Proposal:** Use the `_agents` label and SVCB/TXT records to discover AI agents within a domain (e.g., `_agents.example.com`). * **Discussion:** Paul Hoffman and Ralf Weber argued that the DNS should not be used for complex semantic discovery of AI capabilities and recommended this work move to a specialized BoF or the Applications area. Jim Reid advised against the abuse of TXT records. ## Decisions and Action Items * **Root Zone Proposals:** The Chairs will look for volunteers to coordinate a requirements/problem statement document to reconcile the "Root Cache" and "Local Root" efforts. * **DNS Filtering Transparency:** There was significant support for adoption; the Chairs will take the call for adoption of `draft-nottingham-dnsop-dns-filtering-transparency` to the mailing list. * **RRset Ordering:** The author will produce a -01 version narrowing the scope to CNAME/DNAME processing based on mailing list feedback. ## Next Steps * **AI Discovery / DynDNS2:** These items were dispatched out of DNSOP. Proponents are encouraged to seek a BoF or discuss with Area Directors for a more appropriate home (likely Applications or a new WG). * **Zone Transfer URI:** Wes Hardaker’s proposed XFR URI scheme may be split off and progressed independently as it has utility beyond the Local Root use case.