[Comments-root-name-service-implementation-27oct20] Verisign Comments on Recommendations for ICANN's Root Name Service Strategy and Implementation

[Kane, Pat]

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/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/comments-root-name-service-implementation-27oct20/attachments/20201208/93512bf5/attachment.html>