Page History
...
Patrick Vande Walle, At-Large community liaison to the SSAC, originally composed this statement.
A wiki workspace on the ALAC Statement on the Public Call by the Stability, Security, and Resilience of the DNS Review Team (SSR-RT) was posted on 29 March 2011. On 4 April 2011, a call for comments was sent to the ALAC-Announce, Technical Issues Working Group and regional At-Large mailing lists.
...
On 6 April 2011, the enclosed statement was submitted to the public comment for this issue, the relevant staff person, and the Board Secretary, with a note saying that the document was currently undergoing ALAC ratification.
On 8 April 2011, several comments were posted on the At-Large mailing lists following the filing of the second version of this ALAC Statement. Based on input from these comments, the ALAC Executive Committee added an Addendum which modified the consensus response to Question 4 to more broadly represent the diversity of the At-Large community.
On 11 April 2011, the ALAC began a five day vote on the third version (the present document), consisting of the ALAC Statement with the Addendum. This statement was sent to the staff person responsible for this issue and the Board Secretary, with a note saying that this document was currently undergoing the ALAC ratification process.
[End of IntroductionWiki Markup
Statement of the ALAC on the Public Call by the Stability, Security, and Resilience of the DNS Review Team (SSR-RT)
...
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.
Addendum:
Several late comments have come to light since the filing of the first version of this ALAC Statement. Based on input from these comments we have modified our consensus response to Question 4 to more broadly represent the diversity of our community:
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.
Some of our members believe that 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 would include the new gTLD program, where registries and their backend providers are mandated to deploy DNSSEC from day one.
Others believe that the cost and complexity of deploying DNSSEC is likely to decrease with time and therefore look forward to making DNSSEC mandatory for all new gTLDs. As a result, small new registries from developing countries are not likely to be affected as much by higher costs as initially thought.
The long-term benefits of DNSSEC implementation are likely to outweigh its short term trade-offs and the ALAC would therefore cautiously warrant the full deployment of DNSSEC for all new gTLDs, provided smaller sized applicants are allowed a period of adaptation for them to be able to sign their zone.
...
[1[1|#_ftnref1] 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.
