**Session Date/Time:** 04 Nov 2024 17:30 # dnsop ## Summary The DNS Operations (dnsop) working group meeting covered a variety of topics, including updates on current work, presentations on domain verification techniques, updates to RFC 8624, discussion of IPv6 transport guidelines for DNS, updates on RFCs related to transaction security (TKEY and SIG(0)), and a proposal to deprecate the use of DNS64 for NAT64 prefix discovery. The meeting also included hackathon updates and discussion of document adoption. ## Key Discussion Points * **Domain Verification Techniques (DCV):** Discussion centered on the purpose and appropriate use cases of DCV, with emphasis on clarifying that it is a point-in-time validation, not a permanent authorization. There was a suggestion to move the security considerations section to the front of the document. * **RFC 8624 (DNS Cryptographic Algorithm Recommendations):** The discussion included changing "MUST" to "RECOMMENDED" for algorithm use, addressing concerns about mandating multiple algorithms. Also there was discussion about the scope and relation to the algorithm lifecycle draft. * **RFC 3901 (IPv6 Transport Guidelines for DNS):** The group discussed updating the RFC to promote dual-stack resolvers and authoritative servers. The discussion included the question of a comprehensive approach to address address family selection, transport protocol selection, and avoiding fragmentation * **TKEY and SIG(0):** Discussion focused on the need for these mechanisms and potential updates. The viability of the Diffie-Helman exchange keying mode was questioned. The group questioned if the ECDH version has been requested by anyone who will use it. * **DNS64 Deprecation:** The proposed deprecation of DNS64 for NAT64 prefix discovery was discussed, promoting Pref64 as a more supportable alternative. There was support expressed for the deprecation. * **Hackathon Updates:** Several hackathon projects were presented, including chain query requests, DNS greasing, implementation of delegated RRs, multi-signer distributed key management, and post-quantum secure DNSSEC. ## Decisions and Action Items * **Domain Verification Techniques (DCV):** The authors agreed to elevate the security considerations section (specifically section 5.7) to the introduction to clarify the purpose and appropriate use cases of DCV. * **RFC 3901 (IPv6 Transport Guidelines for DNS):** The working group will decide whether to adopt the draft and update RFC 3901 or take a more comprehensive approach with smaller, more atomic documents. This will be discussed on the mailing list. * **DNS64 Deprecation:** The working group will discuss adoption of the draft on the mailing list. ## Next Steps * **Domain Verification Techniques (DCV):** Authors will revise the draft based on the discussion, moving the security considerations section forward. * **Structured DNS Error is** run through the end of the week for working group last call. * **RFC 8624 and associated "must not" documents**: These will be considered ready for working group last call * **RFC 3901 (IPv6 Transport Guidelines for DNS):** The working group will discuss adoption of the draft on the mailing list, considering whether to split it into smaller, more focused documents. Liaison with the IPv6 working group will also be considered. * Authors (Crocker and Housley) to send a note about their algorithm lifestyle document * Chairs will send out a note to Danes Hop when they do put the multi-Q types in working group last call. --- **Session Date/Time:** 07 Nov 2024 17:30 # dnsop ## Summary The DNSOP working group held its second session, focusing on the following presentations: * Integration of DNSW domain names into application environments * Extended DNS error codes * Dot internal private use * Upper limit values for DNS The meeting included discussions on potential adoption of drafts, the applicability of certain DNS concepts, and the need for further exploration of certain aspects. ## Key Discussion Points * **Integration of DNSW domain names:** The discussion focused on the motivations and challenges of integrating DNS domain names into application environments, particularly new use cases such as blockchain and AI. Concerns were raised about lifecycle management and the potential for inadvertent name collisions. There was support for the WG to consider adopting the draft. * **Extended DNS error codes:** The debate centered around whether to add specific or general error codes and the need for guidance on using new error codes. Warren Kumari noted the ongoing discussion within the IESG regarding internet drafts being referenced in registries. There were concerns about whether an error code for local routes had merit. * **Dot internal private use:** Discussion included whether `.internal` should be treated as a special use domain name akin to RFC 1918 addresses and whether a formal delegation should occur. Opinions differed on the IETF's involvement in this matter. The document authors indicated that the document was initally intended as an informational RFC. * **Upper limit values for DNS:** The presentation proposed setting upper limits on DNS parameters to mitigate resource depletion and DoS attacks. Discussion focused on the practical challenges of setting and maintaining these limits, the risk of ossification, and the impact on diverse network deployments. ## Decisions and Action Items * **Integration of DNSW domain names:** The chairs will schedule a working group call for adoption after IETF 121. * **Dot internal private use:** Action item to consider whether to adopt the document as a working group item, considering the benefits of working group consensus. * **Upper limit values for DNS:** Action item to continue discussion on the mailing list and to explore documenting existing implicit limits. ## Next Steps * Continue discussion on the mailing lists for all presented drafts. * Schedule a working group call for adoption of the `Integration of DNSW domain names` draft. * Further analyze and refine the content and status of the `Dot internal private use` draft based on working group feedback. * Further explore the concept of upper limits and consult with DNS implementers, including documentation on existing undocumented limits for `Upper limit values for DNS`.