Verisign offers the following comments on the document ICANN's Root Name Service Strategy and Implementation that was recently published by ICANN's Office of the CTO (OCTO).[1] We appreciate ICANN's continued investment in the Domain Name System Security Extensions (DNSSEC) and encourage further efforts to promote DNSSEC validation by resolvers. While DNSSEC will help ensure the integrity of the data delivered, the document puts forth concerns around the confidentiality of DNS queries. "Specifically, in the case where the query/response streams to the root servers are subject to eavesdropping, the deployment of privacy-enhancing mechanisms that may be standardized in the future would mitigate the risk". Unless we are misunderstanding, this refers to DNS encryption, a mechanism that is not yet standardized for resolver-to-authoritative exchange. DNS encryption, at any part of the DNS resolution ecosystem introduces operational risk[2]. The strategy for DNS encryption in this document is unclear and foregoes considerations of the appropriate risk / benefit tradeoff and motivation to deploy DNS encryption at the navigational levels of the DNS hierarchy, including the root and top-level domains. While the document recognizes the privacy benefits of techniques such as qname minimization as being on a "different front", we believe[3] that rather than focusing on whether to deploy encryption for a particular exchange in the DNS resolution ecosystem, it is better to ask how to address the information protection objectives for that exchange - whether by encryption, alternative techniques or some combination thereof. Qname minimized DNS traffic from resolvers is inherently less sensitive, particularly at the root and TLD levels. In addition to qname minimization, we encourage ICANN to also draw attention to other low-impact techniques for reducing the sensitivity of the resolver-to-root exchange, including NXDOMAIN Cut Processing and Aggressive DNSSEC Caching. The resolver-to-root exchange enables DNS resolution for all underlying domain names. This exchange provides global navigation for all names, benefiting all resolvers and therefore all clients, and making availability and robustness paramount. Finally, we would encourage ICANN to better distinguish the strategy and implementation plans discussed in this document that will be enacted by ICANN for its own root server and those for the root server system more generally. While we understand the intention of this document to be focused on the ICANN managed root server (IMRS), various strategies, such as encryption, are ambiguous in their distinction between the IMRS and the entirety of the root server system. We are grateful for ICANN OCTO's ongoing attention to the development of their IMRS, and appreciate the opportunity to comment on the new strategy document. [1] ICANN Office of the Chief Technology Officer. ICANN's Root Name Service Strategy and Implementation. OCTO-016, October 26, 2020. https://www.icann.org/en/system/files/files/octo-016-26oct20-en.pdf [1] K. Henderson, T. April, and J. Livingood. Authoritative DNS-over-TLS Operational Considerations. Internet-Draft draft-hal-adot-operational-considerations, October 2019 (expired). https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/ [1] Kaliski, B., A Balanced DNS Information Protection Strategy: Minimize at Root and TLD, Encrypt When Needed Elsewhere. Verisign blog, December 7, 2020. https://blog.verisign.com/security/a-balanced-dns-information-protection-str ategy-minimize-at-root-and-tld-encrypt-when-needed-elsewhere/ Best regards, Pat Kane <file:///C:/Users/pkane/AppData/Roaming/Microsoft/Signatures/dots.gif> Patrick Kane Senior Vice President Verisign Naming Services 12061 Bluemont Way Reston, VA 20190 <http://www.verisigninc.com/> Verisign.com <file:///C:/Users/pkane/AppData/Roaming/Microsoft/Signatures/logo.gif> _____ [1] ICANN Office of the Chief Technology Officer. ICANN's Root Name Service Strategy and Implementation. OCTO-016, October 26, 2020. https://www.icann.org/en/system/files/files/octo-016-26oct20-en.pdf [2] K. Henderson, T. April, and J. Livingood. Authoritative DNS-over-TLS Operational Considerations. Internet-Draft draft-hal-adot-operational-considerations, October 2019 (expired). https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/ [3] Kaliski, B., A Balanced DNS Information Protection Strategy: Minimize at Root and TLD, Encrypt When Needed Elsewhere. Verisign blog, December 7, 2020. https://blog.verisign.com/security/a-balanced-dns-information-protection-str ategy-minimize-at-root-and-tld-encrypt-when-needed-elsewhere/