Page History
- Category: (replace this text with one of the following categories: Administration/Budget, ccTLD, gTLD, IP, ICANN Structure, International Agreement)Topic: (replace this text with a keywords from title) Root Zone
- Topic: SSAC and RSSAC DNS Root Zone Stability Study
- Board meeting date: 3 February 2009
- Resolution number: 2009-02-03-04
- URL for Board minutes/resolution: http://www.icann.org/en/minutes/minutes-03feb09.htm
- Status: (replace this text with: Completed, Ongoing, Suspended)
Summary
(replace this text with the a one-sentence summary of the resolution)
Text
Doug Brent described a proposal, which outlined work done previously on root zone infrastructure (IPv6, DNSSEC, IDNs, new gTLDs). Questions have been raised through the new gTLD process asking for more information on root zone scalability. There is an important need to have a report back to the Board on these changes in aggregate.
The Report calls on SSAC and RSSAC to conduct a joint study, with staff support. He looked to comment from Steve Crocker to comment further.
Steve Crocker provided a bit of background on the question of the size of the root. There is surprisingly little information on this. One of the goals here ought to be to try to document questions to keep questions from coming up again and again. One of the goals is a comprehensive study, to advance the state of the discussion broadly.
Second, we need to look at memory impact on root servers. There is quite a few questions on scaling up of provisioning process, not only impact on root servers, but on DoC, ICANN and VeriSign. Some aspects are related to the rate of change. On the look-up side, what is the traffic load on the root zone. There is a next level of subtlety, on the error models. We should develop a comprehensive picture of all of this.
We've been having more urgent discussions. This will require a funded effort, and this may require more than one consultant. This would be overseen by a steering committee, overseeing by SSAC, RSSAC and staff. Then there's also the question on what time scale we can operate on. I think middle of May is understandable but may not be achievable. We'll see how well we can go.
The Chairman asked whether SSAC and RSSAC to jointly conduct a study. Is that really what we want? Do we really need to look at capacity of root server system to address this? My concern is that we frame these questions properly to meet our needs.
Bruce Tonkin indicated that Steve has given a good description of the scaling issues. I think we have to be careful with respect to new gTLDs, I just want to have the context, the long term scaling issues.
Suzanne Woolf indicated that the issues were the right one's. it's the right question to ask, and there are some organizational challenges about the study, but it will help establish a baseline. We need a baseline and ICANN needs to document that the baseline has been constructed.
The Chair noted that If doesn't state that it will look at staff and operational issues in the anticipation of 10,000 new TLDs.
Katim Touray noted that he wanted to support the call for the study.
Doug Brent noted that this is the opportunity to get an authoritative statement from SSAC and RSSAC on these issues in aggregate.
Suzanne Woolf noted that from RSSAC's perspective, there have been multiple times we've been asked about expansion, up until recently the policy portion had not distilled down to enough to be able to ask the right questions
Bruce Tonkin, noted that he I wonder if the last sentence in the second to last paragraph can be updated. Can we put some sort of scale in the sentence. The study should address changes in scale to the root zone system that result from a substantial increase in the capacity of the current system".
Suzanne Woolf asked whether it makes sense to pass the resolution, and not include the letter in the resolution
Paul Twomey noted that there has been thinking about scaling in the fee planning for the new gTLD process. Bruce Tonkin moved and Demi Getschko seconded the following resolution of the issue.
Board requested the SSAC and RSSAC jointly conduct a study analyzing the impact to security and stability within the DNS root server system of the proposed, referenced implementations.
Text
Whereas, over a short period of time, significant changes to root zone operations are anticipated, including the still-recent addition of IPv6 records to the root, and planned implementation of DNSSEC, IDNs, new cc IDNs, and new generic top level domains.
...
ICANN has conducted a number of efforts to understand the potential security and stability impacts of these changes individually. The RSSAC and SSAC jointly issued an analysis of adding IPv6 records to the root in 2007 (see http://www.icann.org/committees/security/sac018.pdf and IANA's report at http://www.iana.org/reports/2008/root-aaaa-announcement.html). The addition of IDNs to the root has been the subject of significant advance planning, and an extended real-world testbed (see for example SSAC's report at http://www.icann.org/committees/security/sac020.pdf, and IANA's report at http://www.iana.org/reports/2007/testetal-report-01aug2007.html). DNSSEC has benefited from extensive root zone test bed experience and been extensively analyzed though not specifically for the root (see for example http://www.net.informatik.tumuenchen. de/~anja/feldmann/papers/dnssec05.pdf, and the RSTEP report on PIR's DNSSEC implementation at http://www.icann.org/registries/rsep/rstepreport- (http://www.icann.org/registries/rsep/rstepreport\-) pir-dnssec-04jun08.pdf.). Finally, an ICANN staff paper on root zone impact of new TLDs was published for public comment in February, 2008 (see http://icann.org/topics/dns-stability-draft-paper-06feb08.pdf ); this document was based in part on conversations with SSAC and RSSAC members, though not adopted/approved by either committee.
...
The Board further requests the study involve direct participation by senior ICANN technical staff involved with its planned implementations of these activities and to provide necessary support to implement aspects of this study under terms and with ultimate approval of the advisory committees. Additionally, the Board seeks to ensure the process for establishing the study terms, design and implementation will address the technical and operational concerns regarding expanding the DNS root zone that have been expressed on this topic. The Board seeks study findings and recommendations by 15 May 2009.
Implementation Actions
- (replace this text with specific Action Item)
- Responsible entity: (replace this text with the responsible entity: ICANN department, ICANN Community Structure, Board, U.S. Department of Commerce)
- Due date: (replace this text with Due Date)
- Completion date: (replace this text with Date action was implemented, if different from due date)
- (replace this text with specific Action Item)
- Responsible entity: (replace this text with the responsible entity: ICANN department, ICANN Community Structure, Board, U.S. Department of Commerce)
- Due date: (replace this text with Due Date)
- Completion date: (replace this text with Date action was implemented, if different from due date)
Other Related Resolutions
- (replace this text with links to related resolutions)
Additional Information
...
- RSSAC and SSAC develop terms of reference for the Study and appoint a steering committee.
- Responsible entity: RSSAC and SSAC
- Due date: 28 February 2009
- Completion date: TBD
- Senior ICANN technical staff involved and providing support.
- Responsible entity: ICANN Security Staff
- Due date: None specified
- Completion date: TBD
- Process for establishing the study terms, design and implementation addresses the technical and operational concerns regarding expanding the DNS root zone that have been expressed on this topic.
- Responsible entity: RSSAC and SSAC
- Due date: 28 February 2009
- Completion date: TBD
- Study findings and recommendations provided to Board
- Responsible entity: RSSAC and SSAC
- Due date: 15 May 2009
- Completion date: TBD
Other Related Resolutions
- TBD
Additional Information
- No additional funding provided.
Explanatory text does not modify or override Resolutions. See Board Resolutions Page for more information.
