**Session Date/Time:** 22 Jul 2024 20:00 ```markdown # deleg ## Summary The inaugural meeting of the DNS Delegation (deleg) Working Group focused primarily on discussing and refining the initial requirements document for a new delegation mechanism. The goal is to enable authoritative servers to signal capabilities to recursive resolvers, especially concerning transport protocols. Discussions also touched on aliasing, transport, and potential impacts on GTLD operations. The working group indicated strong support for adopting the existing requirements document as a basis for further work. ## Key Discussion Points * **Requirements Document Adoption:** Strong support was voiced for adopting the individual submission as the working group's requirements document. * **Namespace Semantics:** Clarification needed regarding the requirement that the new mechanism not change current namespace semantics. The intent is to not break existing NS delegations. * **Multiple Operator Support:** Explicitly adding a requirement to support multiple operators for a zone was deemed important. * **Backwards Compatibility:** Debate on whether NS records should always be required, and how to ensure incremental deployability of the new mechanism. A "flag day" scenario should be avoided. * **Parent-Child Communication:** Whether the new protocol should include a mechanism for children to notify parents of delegation updates. Existing DNS NOTIFY mechanisms might address this. * **Aliasing Requirements:** Discussion of requirements for aliasing, including multiple targets, transport specifications, and keying material distribution. * **Transport Requirements:** Discussion of requirements for specifying multiple transport types (e.g., DO53, DOT, DOQ). Whether to include DOH was debated. * **GTLD Considerations:** Awareness of ICANN consensus policies and the need for EPP/RDAP extensions for provisioning the new mechanism in GTLDs. A new RR type, if chosen, requires provisioning through EPP. * **Zone Cut Placement:** A presentation discussed the implications of placing the new delegation information at the parent side of the zone cut versus elsewhere in the zone. Considerations included impact on DNSSEC, deployability, and query overhead. * **Consistency between NS and DELEG:** The draft should discuss what should or shouldn't happen with regard to consistencies between NS and DELEG records during the transition period. * **Meta Delegation Information:** The proposed meta way of expressing delegation information. The DNS protocol and potential impact on zone take downs. ## Decisions and Action Items * **Adopt Requirements Document:** The working group agreed to adopt the individual submission for the requirements document as a basis for further work. * **Update Requirements Document:** The authors of the requirements document will incorporate feedback from the meeting and mailing list, including: * Clarifying namespace semantics. * Explicitly stating the requirement for multiple operator support. * Addressing concerns about future restrictions regarding NS records and delegation. * Including discussion on consistency between NS and DELEG records. * **Chair Action Items:** * Dwayne and Brian will Post Paul Hoffman's text to the working group GitHub repository. * Chairs to evaluate need for interim meeting based on list participation. * **Consider separate DSNIX Changes:** The working group will consider documenting DNSX protocol changes separately. ## Next Steps * **Mailing List Discussion:** Continue discussion and refinement of requirements on the mailing list. * **Requirements Document Revision:** Publish an updated requirements document incorporating meeting feedback. * **Aim for Requirements Document Completion:** Working group aims to complete the requirements document (i.e., reach IETF Last Call) before the next IETF meeting. * **Begin Protocol Discussion:** After requirements document completion, begin discussion of specific protocol proposals.