Public Call by the Stability, Security, and Resilience of the DNS Review Team (SSR-RT)
Questions and request for input from the community based on the SSR-RT
1. Existing analysis of the impact of ICANN’s responsibilities, as stated in the bylaws and related documents, on the Stability, Security, and Resilience of the DNS.
2. Opinions on the limitations of the scope of ICANN’s responsibilities, as stated in the bylaws and related documents, on the Stability, Security, and Resilience of the DNS.
We believe that the current limitations in scope are adequate.
3. Recent opinion on the DNS CERT proposal and on the need to coordinate/support detection and management of attacks/incidents to DNS
While the DNS CERT proposal is an interesting one that should be further examined, we believe it is outside ICANN's mandate. Further, this could position ICANN as a judge and party on some issue. The community would be better served by an independent organization running the CERT.
4. Experiences, difficulties, unexpected advantages, and lessons learned in the implementation of DNSSEC.
Recent events, like the one that happened to .fr a few days ago, due to a software bug, seem to demonstrate the infrastructure may not be ready yet for the full, ubiquitous deployment of DNSSEC. Relaxing the pressure for the deployment of DNSSEC and proceeding carefully would allow DNS operators to gain additional experience and mitigate the risks. This includes the new gTLD program, where operators are encouraged to deploy DNSSEC from day one.
5. Sources of risk analysis for the DNS, as well as contingency planning, business continuity planning (BCP) and related work for the DNS.
6. Original solutions proposed to increase the Stability, Security, and Resilience of the DNS at the protocol level, including the design of the Root Server system.
While we believe the current system of hierarchical DNS works relatively well from a technical point of view, we think that one of the roles of ICANN would be to foster research on alternative naming systems that would allow more diversity at all levels of the hierarchy. For example, having multiple registries managing domains under the same TLD.
7. Processes used by DNS users and operators to guarantee that the Risk Analysis related to the DNS is comprehensive and updated.
8. Analysis of the relationships of ICANN with “contracted parties” (registries and registrars) as well as others (ccTLDs not bound contractually to ICANN, Root Server Operators, etc.)
While this has been a controversial issue, we believe that it would be the greater interest of the Internet community to have clear agreements with the root server operators. Right now, the belief is that the honour to be able to run a root server is enough to motivate the operators to offer a good service. And although no significant issues happened up to now with root server operations we feel we should be better safe than sorry. At the very least, there should be a process in place to be able to replace a root server operator in case of a systemic failure or underperformance.
Among the non-contracted parties, one should also mention domain name resellers and WHOIS proxy/privacy providers. Those are unaccountable to ICANN, and have been involved in many issues in the past. One suggestion from the At-Large would be to have a clear accreditation mechanism for these and, of course, to include provisions in the RAA to prevent registrars from working with unaccredited resellers or proxy providers.
9. Involvement, present or possible, of non-ICANN entities in the design, implementation, operation, and evolution of the DNS, in its potential impact on the Stability, Security, and Resilience of the DNS.
To some extent, the IETF and IAB are part of the design of the DNS. DNSSEC, and the DNS protocol in general are still work in progress. There is a need to reinforce the link with the IETF community, including having clear agendas and timelines for features and changes in the DNS protocols, based on the operators and users experience.
As an example, DNSSEC is a server-to-server protocol. The client computer side is unaware of responses to DNSSEC queries. There may be a need at a later stage to allow the clients be able to process responses from DNSSEC queries. The IETF does not have a formal process in place to consult the wider Internet community. The ICANN community, because of its diversity, could become an aggregator of the users needs, and submit them to the IETF.
10. Solutions/Proposals on Root Server Governance, including transparency, accountability, security/performance measurements, policies, accessibility and the opportunity to have more RS operators
The current context of root server operations is neither transparent, nor accountable. This is mostly the result of a historic situation.
The deployment of DNSSEC and IPv6 in the root has demonstrated that the technical limit of 13 root name servers in the root zone (i.e the limit of 512 bytes in a UDP packet) is no more relevant. This would allow to add more root servers and better respond to the changes in Internet usage in geographic terms, although we acknowledge that anycasting of the several root servers has addressed this to some extent.
11. Studies or informed opinion related to large-scale risks that can alter the environment of the DNS, and indicators, metrics or harbingers of such risks, including models/frameworks to measure Security, Stability and Resilience of the DNS as a system.
