**Session Date/Time:** 22 Jul 2024 22:30 # dnsop ## Summary The DNSOP working group met for its first session, covering updates on active drafts, hackathon results, and presentations on generalized DNS notifies, delegation synchronization, NS revalidation, and secure name server selection. Key discussions revolved around potential adoption of drafts, security considerations, and implementation details. ## Key Discussion Points * **Generalized DNS Notifies:** * Discussion on using SVCB records versus a new "_desync" record for announcing endpoints. * Clarification needed on the meaning of "notify" in the context of parent-to-child communication versus primary-to-secondary. * Considerations for how registrars might adopt the proposed mechanism. * Agreement that bootstrap notifications should not be treated differently. * **Delegation Synchronization via DNS Update:** * Implementations are almost complete in both generalized notifications and the update. * Update is easier in a parent end, because we get a DNS update message. * Desire for working group adoption to further the draft. * Henri hopes to deprecate six-0 algorithm (asymmetric encryption) so bind server won't support it. * **NS Revalidation:** * Security benefit comes from the revalidated nameserver being more secure. * Concerns raised about the aggressiveness of the policy needed for real security benefits and the lack of clarity in error handling, especially with failures during revalidation. * The importance of addressing issues where parents and child zone data do not match was emphasized. * **Secure Name Server Selection:** * Discussion focused on vulnerabilities in existing NS selection algorithms and potential mitigations. * Concerns raised that the document focuses on implementation vulnerabilities rather than specification issues. * Suggestions to tone down language in the draft because it contains errors. ## Decisions and Action Items * **Generalized DNS Notifies:** Continue discussion on the mailing list, including the name used. * **Delegation Synchronization via DNS Update:** Chairs to discuss working group adoption of the draft and schedule accordingly. * **NS Revalidation:** The document will be worked on and revised. * **Secure Name Server Selection:** Authors to revise document. ## Next Steps * Continue discussions on the mailing list for each of the drafts presented. * Chairs to schedule a call for adoption for "Delegation Synchronization via DNS Update" * Working group's second session on Thursday to continue discussions on remaining topics. --- **Session Date/Time:** 26 Jul 2024 01:30 # dnsop ## Summary The DNSOP session covered several topics including a discussion on deprecating or updating RFC 7050 related to DNS64, an update on the DNS-based load balancing side meeting, client authentication recommendations for encrypted DNS, and a presentation on a method to prevent zone walking in DNSSEC. The session involved lively discussions and included input from various experts in the field. ## Key Discussion Points * **RFC 7050 and DNS64:** * Discussion on deprecating or updating RFC 7050, which defines secure channels in the context of DNS64 prefix discovery. * Concerns raised about the current definition of "secure channel" in RFC 7050, particularly regarding the use of IPSEC or link-layer security. * Suggestions to deprecate DNS64 and update RFC 7050 to reflect modern practices like using encrypted DNS and DHCP/router advertisements. * Arguments presented that DNS64 is unnecessary and causes issues with DNSSEC validation. * **DNS-Based Load Balancing Side Meeting:** * Update on the load balancing side meeting, which explored various ideas related to DNS-based traffic targeting and GSLB. * Discussion on whether to focus on internal improvements to authoritative name servers or modifications to protocols between resolvers and authoritative name servers. * Request for suggestions on a name for a new mailing list dedicated to DNS-based load balancing discussions. * **Client Authentication Recommendations for Encrypted DNS:** * Presentation on a draft recommending best practices for client authentication with encrypted DNS, particularly in scenarios where the same entity owns both the DNS server and client. * The draft recommends MTLS for client authentication due to its reusability across different encrypted DNS protocols and amortization over connections. * Concerns were raised about user experience and the potential for leaking identity if client authentication is not implemented correctly. * Debate about the scope of the document and whether it should provide specific recommendations or simply document the tradeoffs of different authentication mechanisms. * **Zone Walking Prevention in DNSSEC:** * Presentation on a method called "zone hopping" to prevent zone walking in DNSSEC by selectively removing NSEC records for less critical domains. * Concerns raised about the impact of aggressive NSEC caching on the effectiveness of this approach. * Arguments presented that zone walking is not a significant problem because the information can be obtained through other means like passive DNS. * Counterarguments suggest that passive DNS has limitations and that zone walking can expose sensitive domain names that should not be public. ## Decisions and Action Items * **RFC 7050:** The working group seemed to lean towards deprecating RFC 7050. Tommy Jensen will need to consider this feedback. * **Load Balancing Mailing List:** The group will create a mailing list for DNS-based load balancing discussions. A name is required. Suggest possible names on the DNSOP mailing list. * **Client Authentication for Encrypted DNS:** Warren Kumari to conduct a poll to determine if this work should be done in DNSOP. ## Next Steps * Tommy Jensen to consider feedback on RFC 7050 and DNS64, and determine if deprecation is appropriate. * Create a mailing list for DNS-based load balancing, after a name is decided on the DNSOP list. * Warren Kumari will present the results of the poll regarding client authentication recommendations for encrypted DNS to the IESG. * Fatima Bonas to revise the zone hopping prevention draft based on the feedback received.