dnsop

Summary

This was the first dnsop working group session on Monday, featuring introductions of new leadership and discussion of four main technical drafts. The session included welcome remarks for new working group chair Andre and technical advisor Jim, along with farewell acknowledgments to outgoing chairs Suzanne and Tim. The main technical discussions focused on DNS structured errors, public resolver errors, IPv6 transport guidelines, and domain verification techniques.

Key Discussion Points

Leadership Changes and Administrative Updates

New Leadership: Andre introduced as new working group chair alongside existing chair Benno
Support Team: Shuman and Peter confirmed as secretariat support, Jim as technical advisor
Document Status: Multiple RFCs in editor queue expected to be published before next meeting
Hackathon Results: DNS table work included residual case synchronization, private OIDs/algorithms for post-quantum crypto testing, and MTL mode implementation in BIND

DNS Structured Errors Draft Discussion

Current State: Draft returned to working group after IESG last call due to feedback
Key Issues:
- Use of EDE option in queries vs responses (violates RFC 8914)
- Two proposed solutions: new option code or server-side only responses
- Sub-error code categories - currently limited to security-related codes
- Trust model for displaying information (trusted vs untrusted resolvers)
Implementation Feedback: Apple and Mozilla representatives confirmed interest and existing implementations

Public Resolver Errors Draft

Use Case: Making web censorship more transparent, specifically for web browsers
Required Information: Identity of blocking party, blocking authority, reason for blocking, URI for more information
Security Challenge: Information is unauthenticated and could be misused for attacks
Browser Vendor Input: Chrome and Firefox representatives confirmed interest and described trust mechanisms for determining when to display information

IPv6 Transport Guidelines (RFC 3901bis)

Problem: RFC 3901 from 2004 treats IPv6 as optional, leading to lower IPv6 adoption in DNS
Research Results:
- IPv4 and IPv6 resolution performance within 3% difference
- Fragmentation has minimal impact on DNS resolution
- Misconfigured IPv6 has greater impact than fragment dropping
Proposed Changes: Make IPv4 and IPv6 equal requirements for authoritative servers

Domain Verification Techniques

Recent Changes: Version 0.09 introduces distinction between one-off vs persistent validation
Open Issues:
- Token definition (random vs unique tokens)
- DNSSEC validation requirement (should vs must)
- Process concerns raised about extensive changes without working group discussion

Decisions and Action Items

DNS Structured Errors

Decision Needed: Choose between new option code (Option A) or server-side only responses (Option B)
Implementation Input: Strong preference from implementers for client signaling capability
Security Model: Discussion needed on trusted vs untrusted resolver behavior

Public Resolver Errors

Convergence Needed: Determine if information should be limited in protocol specification or handled via security considerations
Browser Vendor Approach: Preference for receiving all data and making trust decisions in client

Process Decisions

Interim Meeting: Likely needed for structured DNS errors discussion due to time constraints
Working Group Consideration: Suggestion to charter focused working group for censorship-related work
Technical Advisor Input: Recommendation to combine drafts through interim meetings rather than new working group

Next Steps

Immediate Actions

CDS Consistency Draft: Last call to be closed this week
Domain Verification: Authors to address process concerns about changes made without working group discussion
IPv6 Transport: Document appears ready for working group last call pending final review

Upcoming Sessions

Friday Session: Next dnsop meeting scheduled
Interim Meetings: Planned for DNS structured errors discussion
Mailing List Discussion: Continued technical discussion required for all drafts

Document Progression

DNS Automation: Needs revision before last call
Domain Verification: Ready for last call, scheduled for agenda
DNS Revalidation: Needs new revision and last call scheduling
IPv6 Transport: Nearing last call readiness

The session concluded with emphasis on continuing discussions on the mailing list rather than only during meetings, and reminder of the Friday session in a different room.

Session Date/Time: 25 Jul 2025 09:30

dnsop

Summary

The second DNS Operations (dnsop) session on Friday covered nine draft presentations and multiple adoption considerations. Key topics included persistent DNS references, DS automation recommendations, service binding mappings, DNSSEC algorithm rules, debugging techniques, zone delegation methods, cache synchronization, scanner notifications, and transport signaling. The working group received numerous requests for draft adoptions, with chairs noting they could only accommodate two-thirds of agenda requests and will deliberate on adoptions via the mailing list.

Key Discussion Points

Best Practices for Persistent References in DNS

Presenter: Andrew Kayser
Discussion on using DNSSEC for cryptographically verifiable associations between DNS domain names and persistent references (CAA records, wallet addresses, social media handles)
Convergence potential with the DCV BCP draft currently in RFC Editor queue
Agreement on using DNSSEC validation when zones are signed, rather than requiring DNSSEC everywhere

Operational Recommendations for DS Automation

Presenter: Peter (representing draft for GTLD registries)
Five main recommendation areas: validity checks, TTL management, error reporting, EPP locks handling, and multiple submission sources
ICANN currently blocks GTLD registries from DS automation due to unclear operational practices
Key contentious points: email notifications scaling, registry lock interpretation, and periodic validation requirements

Service Binding Mapping for Background Requests

Presenter: Gauta Makiawate
Proposal for new SVCB parameter "background priority" to distinguish latency-sensitive vs background traffic
Allows clients to dynamically discover endpoints optimized for background requests
Several concerns raised about filtering mechanisms and naming conventions

Multiple Algorithm Rules in DNSSEC

Presenter: Shumon
Proposal to selectively relax DNSSEC signing requirements for "universal algorithms" (8, 13)
Strong opposition from Mark Andrews and Jim Reid citing security concerns and complexity
Support from Philip with modifications to validator requirements

DNS Debugging with probe.resolver.arpa

Presenter: Paul Hoffman
Proposes standardized domain for DNS debugging instead of example.com
Testing shows comparable performance and reliability
Addresses privacy concerns of client identification in debug queries

Zone Cut to Nowhere

Presenter: Joe Abley
Mechanism for handling namespace conflicts between public and private DNS
Uses empty delegation target (dot) to avoid cryptographic proof of non-existence
Mark Andrews expressed safety concerns about resolver behavior

Synchronizing Caches Between DNS Resolvers

Presenter: Not specified in transcript
Proposal for cache sharing between cooperating resolvers in trusted networks
Concerns raised about ECS complications, DNSSEC validation status, and practical benefits

Generalized Notifications Extensions

Presenter: Johan
Two small extensions for scanner frequency signaling and negative signaling
Uses port numbers to indicate scanner frequency when no notification receiver exists
Discussion on timer units (seconds vs minutes) and registrar vs registry scanner roles

Opportunistic DNS Transport Signaling

Presenter: Johan
Pre-DELEG solution for signaling DOT/DOQ support via SVCB records in additional section
Addresses operational concerns with blind probing approach from RFC 9539
Ben Schwartz noted this is already possible within existing RFC 9461 framework

Decisions and Action Items

Working Group Adoption: Chairs will deliberate on multiple adoption requests and communicate decisions via mailing list due to high volume of requests
Draft Convergence: Authors of persistent references and DCV BCP drafts to continue discussions on potential merger
Mailing List Follow-up: Several presentations explicitly directed further discussion to the mailing list due to time constraints

Next Steps

Continue detailed discussions on all presented drafts via the dnsop mailing list
Authors to incorporate feedback received during presentations
Working group chairs to announce adoption decisions for pending drafts
Further collaboration between related draft authors (particularly persistent references and DCV BCP)
Additional technical analysis needed for several proposals, particularly cache synchronization measurements and zone cut delegation safety