Markdown Version | Session Recording

Session Date/Time: 21 Jul 2025 07:30

DNS Delegation (deleg) Working Group Meeting Minutes

Summary

The IETF deleg working group met to discuss the current status of the DNS delegation protocol draft and several key technical issues. The session covered updates to the base protocol specification, discussions on nameless delegations, authoritative delegation type records, and the choice of record types for include mode operations. Key topics included protocol design decisions, compatibility considerations, and future extensibility mechanisms.

Key Discussion Points

Base Protocol Updates (Tahl Presenter)

• Recent Changes: Published draft with substantial modifications including:
  • New restriction: DELEG records must not fallback to NS records for downgrade protection
  • New authoritative delegations type flag in DNSKEY record
  • Extended DNS error code for "new delegation only" scenarios
  • Updates to RFCs 6672 and 6840
• Planned Updates:
  • Service parameter naming changes (glue4/glue6 → ip4/ip6)
  • Need to define DELEG awareness in transfer protocols
  • Security considerations section required
  • Proofreading and editorial improvements needed

Nameless Delegations Discussion (Paul Hoffman)

• Proposal: Add option for direct IP addresses without names in DELEG records
• Arguments For:
  • If not added now, cannot be added later due to protocol assumptions
  • Resolvers ultimately only need addresses for functionality
  • Avoids potential errors from fake name generation
• Arguments Against:
  • Easy to generate synthetic names when needed
  • Adds complexity during transition period
  • May create operational inconsistencies

Technical Considerations

• Response Codes: Debate over appropriate response (NXDOMAIN vs SERVFAIL vs REFUSED) when legacy resolvers query DELEG-only delegations
• Caching Issues: NXDOMAIN responses require SOA records for proper caching behavior
• Operational Impact: Concerns about deployment complexity and troubleshooting difficulties

Authoritative Delegation Type Records (Roy Arends)

• Proposal: Reserve a range of RR types for future delegation extensions rather than single type allocation
• Benefits:
  • Avoid costly retrofitting for future delegation types
  • Enable unknown RR handling for secondary servers
  • Simplify future protocol extensions
• Implementation: Would require NSEC/NSEC3 records in all delegation responses for the reserved range

Include Mode Record Types (Paul Hoffman)

• Current Approach: Use SVCB records as targets for include mode
• Alternative: Define new RR type specifically for delegation information
• Key Issues:
  • Semantic differences between DELEG and SVCB requirements
  • Transport parameter compatibility
  • Priority handling preferences within working group

Decisions and Action Items

Decisions Made

• Working group showed mixed consensus on nameless delegations with valid arguments on both sides
• No final decision on response codes for legacy resolver compatibility
• Interest expressed in exploring RR type range allocation, though venue (deleg WG vs dnsop) remains unclear

Action Items

• Chairs: Start mailing list discussions on:
  • RR type range allocation proposal and appropriate venue
  • Semantic requirements definition before format decisions
• Authors: Address editorial issues and complete security considerations section
• Working Group: Continue discussion on include mode record type selection based on semantic requirements

Next Steps

1. Mailing List Discussions: Targeted threads on specific technical decisions rather than broad format debates
2. Semantic Definition: Focus on defining what the protocol should do before determining wire format
3. Implementation Guidance: Develop clearer specifications for resolver behavior in mixed delegation scenarios
4. Charter Considerations: Determine if RR type range work belongs in deleg WG or should move to dnsop
5. Base Specification Refinement: Complete remaining editorial work and add required security considerations

The meeting concluded with emphasis on resolving semantic questions first, then determining appropriate wire formats and record type structures to support those semantics.