Markdown Version | Transcript | Recording 1 | Recording 2 | Session Materials

Session Date/Time: 16 Mar 2026 03:30

DNSOP

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 Draft: draft-ietf-dnsop-delegation-mgmt-via-ddns

• 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

• 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

• 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

• 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

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 (as an update to RFC 8806), followed by Wes Hardaker presenting Local Root.

• 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, 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. 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, 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.

• 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.

• 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.

Related Documents

draft-abley-dnsop-rrset-ordering, draft-ietf-dnsop-delegation-mgmt-via-ddns, draft-ietf-dnsop-delext, draft-ietf-dnsop-domain-verification-techniques, draft-ietf-dnsop-dry-run-dnssec, draft-ietf-dnsop-ds-automation, draft-ietf-dnsop-integration, draft-ietf-dnsop-ns-revalidation, draft-ietf-dnsop-rfc9364bis, draft-ietf-dnsop-structured-dns-error, draft-nottingham-dnsop-dns-filtering-transparency