[Editors note: Below is a summary of discussions which will feed into a report on the “DNSSEC: Securing a Critical Internet Resource” workshop held at IGF-Rio on November 14th.]
This informative workshop, co-sponsored by the Internet Governance Project, CGI.br, and EuroISPA, drew approximately 80-90 attendees from government, civil society, the private sector and technical communities. While the multi-stakeholder panel brought a diversity of opinions regarding DNS Security Extensions (DNSSEC), they agreed that improving the security of the Internet’s infrastructure is an important activity which should be pursued.
In general, there are two camps concerning the deployment of DNSSEC, which is a technical standard that requires coordination among many actors to be successfully deployed on a wide-scale basis. One side is ready to proceed with deployment, particularly the hurdle of creating a “trust anchor” key and digitally signing the root zone file. The other is more cautious in its approach, believing that the successful deployment of DNSSEC is subject to many open technical and governance questions.
One central stakeholder is top level domain (TLD) registries. For TLD registries that wish to deploy DNSSEC, some current operating procedures will need to be redesigned, and some new procedures will need to be created with regard to key management and rollover. While some registries (e.g., .se, .uk, .br) are actively pursuing making these changes, estimates of difficulty and cost vary by registry. IANA, which is responsible for several TLD zones critical to the Internet’s functioning, has made substantial progress and successfully deployed DNSSEC in a test bed environment.
The panelist from Nominet conveyed points made in a recently released position paper. Nominet believes that a single entity, IANA, should be responsible for root signing activities, and that any governance questions should be discussed as part of the current dialogue towards “enhanced cooperation.” Another panelist, speaking as a representative member of RIPE, supports expediting the root signing process, and argued that DNSSEC does not fundamentally change the current root management process or actor relationships. He also expressed concern that the deployment of DNSSEC at the root should not be held up because of political issues which can be resolved ex post.
However, the panelist from .de, the world’s largest ccTLD, noted that deploying DNSSEC at the Internet’s root entails making a decision about whether to dedicate trust to one or multiple entities. To them, it is not entirely clear in the former case what power or implications are associated with a single entity holding that position. Neither is it clear that there is demand for DNSSEC. The panelist representing CGI.br also expressed that a better understanding is needed of the possible vulnerabilities associated with a single government having authority over the root zone file, especially given that .br is currently signing a zone for use by it’s financial institutions.
Many interesting questions and comments were raised during the panel-audience discussion.
The panelist representing RIPE argued that deploying DNSSEC at the root would not prevent DNS resolver operators from using another root if they chose too. However, an audience member from the academic community pointed out that it is well-known network effects and associated costs of making that switch would make such an action improbable. Another issue raised was that it is unclear exactly how the deployment of DNSSEC at the root zone will affect root server operators, and particularly their ability to provide an informal check against activities that occur at the root zone (e.g., their ability to roll back to previously generated root zone file).
Audience members noted other technical solutions to signing the root zone which would create alternative, multiple trust anchors. However, it was noted that one such option, DLV, is not standardized in the IETF. A manager from .se, which has deployed DNSSEC in its zone, noted that the Internet Service Providers (ISPs) with whom they’ve spoken are not willing to configure and manage more than 2-3 trust anchors in their resolver software. There was some debate about concentrating root zone editing, trust anchor key creation, and root zone signing with any single entity. A longtime participant in the standard’s development expressed concern, and instead suggested that these roles be distributed similar to auditing-company relationships.
Inventory of events and actors related to the issue under discussion
Signing the root zone file was identified in the workshop and in a recent ccNSO survey of ccTLD operators as a major step in the widespread deployment of DNSSEC.
While IANA has largely developed processes for signing zones for which it is authoritative, it is still unclear at this time who will be responsible for root zone signing activities.
The interaction between parties that maintain the root zone (ICANN/IANA/VeriSign) and root server operators (RSOs) is critical to the successful functioning of the Internet’s Domain Name System (as noted in another workshop). While some RSOs currently state they are able to support the deployment of DNSSEC at the root, the informal nature of the relationship between ICANN/IANA and RSOs leaves the level of support unclear.
The DNSSEC-Deployment group is currently discussing issues related to the deployment of DNSSEC. The group has facilitated meetings at the last several ICANN meetings.
Possible follow-up
In general, given its widespread impact, it would be beneficial to increase the transparency of any decision-making concerning deployment of DNSSEC at the root. E.g., the recent briefing to ICANN’s GAC on DNSSEC was open to some private sector actors (ccTLDs) but not civil society. It would also likely be beneficial for all parties involved to have a greater understanding of the impact or possible vulnerabilities of a single entity overseeing the root signing process.
IANA has outlined a zone signing process which may be applicable to signing the root zone. They have also stated they are committed to making the process as open and transparent as possible. ICANN/IANA could report periodically on the status of assuming any root management activity from VeriSign. Additionally, the process outlined by IANA includes real possibilities to distribute authority for root zone key management (i.e., generation, signing) which could be explored more fully.
