ALAC Comments on the Public Call by the Stability, Security, and Resilience of the DNS Review Team (SSR-RT) - March 2011

Public Comment Announcement: The Security, Stability and Resiliency of the DNS Review Team Set of Issues (ends 6 April 11)


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.

The fairly frequent recourse to "Stability, Security, and Resilience" is currently lacking definition, as a policy construct, and as a phenomena sufficiently understood to support measurement.

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. However, in order to prevent confusion, it should be stated that the WHOIS issue is not a stability, security and resilience aspect of the DNS. Both issues are technically independent and unrelated. 

While we certainly approve ICANN's decision to focus on the deployment of DNSSEC on a global scale, we point out that it will only become effective and useful for Internet users once this will be adopted and implemented by major TLDs, as well as registrars and registrants. Having signed the root does not mean the work is done. A huge awareness campaign is still needed to convince registrars, registrants, ISPs, CPE manufacturers and others to actually offer support for DNSSEC.

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 issues. 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 weeks 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 all operators in the DNS chain to gain additional experience and mitigate the risks. This includes the new gTLD program, where registries and their backend providers are mandated to deploy DNSSEC from day one. Rather, DNSSEC signing should be advised only when the utility of zone signing and key management justifies the cost, as with all other engineering choices.

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 encourage, help and possibly fund research that would address the challenges and needs of on future naming systems (see footnote 1).

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.)

Among the non-contracted parties, one should 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.

ICANN should continue its current successful approach to obtain formal MoUs with ccTLDs. These exchange of letters are a way to formalize each party's responsibilities in the stability of the DNS.

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.

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.

10.   Solutions/Proposals on Root Server Governance, including transparency, accountability, security/performance measurements, policies, accessibility and the opportunity to have more RS operators

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.

Unknown macro: {footnote}

For example, having multiple registries managing domains under the same TLD. Such proposals have been floating around for a long time. See, for example, the original proposal for the SRS protocol at ftp://ftp.cuhk.edu.hk/pub/doc/ripe/ietf/98dec/drp-minutes-98dec.txt, or academic research on alternative name resolution systems like CoDoNS at http://www.cs.cornell.edu/people/egs/beehive/codons.php.

Unknown macro: {end footnote}
  • No labels

10 Comments

  1. a comment on the reply to question 1 sent to technical-issues@atlarge-lists.icann.org

  2. a comment on the reply to question 3 sent to technical-issues@atlarge-lists.icann.org

  3. a comment on the reply to question 6 sent to technical-issues@atlarge-lists.icann.org

  4. a comment on the reply to question 8 sent to technical-issues@atlarge-lists.icann.org

  5. a comment on the reply to question 10 sent to technical-issues@atlarge-lists.icann.org

  6. a comment on the reply to question 9 sent to technical-issues@atlarge-lists.icann.org

  7. I still oppose delaying the DNSSEC deployment. Only early introduction (especially on new gTLDs) will ensure a propper and working infrastructure, instead of a long term migration phase later on.

    ICANN has to insist on widly deployed security mechanisms ready to be used by the consumers. So ICANN is urged to provide DNSSEC on all DNS levels up to the final delegation to offer the consumer the choice to use this technology.

  8. I also oppose the extension of root nameservers, the 512byte limit is real.

  9. The footnote looks strange because Confluence seems to missing the Adaptavist footnote macro. Please reformat the final document accordingly. 

  10. Please note that Eric Brunner-Williams' replies to the questions are in the technical-issues At-Large List and can be found on:

    http://atlarge-lists.icann.org/pipermail/technical-issues/2011-March/date.html