Just who will be "it" and control the secure DNS root took another turn this week at ICANN-Delhi, when VeriSign unexpectedly announced it would implement a DNSSEC test bed for the root zone either later this year or the beginning of next year. In a discussion that covered root zone management process improvement and DNSSEC test bed implementation, VeriSign's Ken Silva acknowledged that the current process is somewhat of a "black box." The 20+ year telecommunications and security industry exec and former executive technical director at the NSA, cited their current role as publisher of the root zone and its need to be familiar with all the anticipated components that will go into future root zone database management as reason for the initiative.
ccTLD registry operators expressed surprise at the announcement, with one asking how it "fits in the current discussions about signing the root within the community." VeriSign's actions seemed inconsistent with its 2006 settlement agreement with ICANN that calls for planning the transition of root zone management (and specifically notes DNSSEC) to ICANN. Some concern centered on the fact that the test bed seems to duplicate the DNSSEC processes that IANA has been running for over 6 months. It was unclear how synchronization between the test beds of the critical DS records (which contain a child zone's public key information used to validate domain names) will be maintained.
It was difficult to tell if the announcement caught other ICANN bodies off guard or not. In the DNSSEC workshop on Monday, the SSAC Chair explained away VeriSign's parallel-world test environment as a curious form of unit testing, where interacting operational actors develop and test systems independently and then integrate them at a future time. Typically defining the roles of each actor is done in advance of any software system requirements development.
The transcript of Tuesday's ccNSO session suggested that those within ICANN who are closely tied to US government efforts to see DNSSEC deployed may not have been entirely unaware of VeriSign's plans. In responding to questions, Silva seemed to indicate that their test bed was "based on" earlier work done by a firm run by the SSAC Chair, in addition to IANA working group documents. The referred to work is likely the DHS-sponsored specification that raised much controversy. Seeking to address concerns about root zone key control, Silva described the system to be built as "key signing key agnostic." According to Silva, it didn't matter to VeriSign who maintained the key signing key, they were focused on generating and using the root zone signing key, and leveraging their experience with existing certificate signing and PKI processes.
Attempting to reassure ccTLD operators that VeriSign wasn't making an end run around the broader Internet community's efforts to secure the root, while still emphasizing the critical and powerful role VeriSign plays in core Internet functions and as the world's largest registry, Silva continued:
"[VeriSign] didn't build — the trial we're building is not dependent on our keys or our signatures in any way down the road once this goes into a production mode, assuming it will go into a production mode. But we operate…the root servers. We generate the root zone and we currently house the database for that system, so we felt it was necessary to have a process that worked end-to-end all the way through the registration process — or, excuse me, the update process and addition process all the way through cutting the zone and publishing the zone."
He concluded:
"As we move forward and we understand the process better, part of this automated root zone management process that we're already working on for the existing root zone process will then incorporate all of the elements including the steps needed to sign, the steps needed to enter the records in and then ultimately publish the signed zone."
All of this suggests that despite IANA's largely transparent efforts completed to date, the situation is completely fluid at this point. The obvious question is what role(s) exactly does VeriSign think (or is being told) it will assume in securing the root? It's too early to know, but the threat of losing control over critical functions like digitally signing the root to IANA, only exacerbated by ICANN's increasingly loud calls for independence, could eventually convince the US government to choose VeriSign as its new agent of DNS root control.
Dear Brenden Kuerbis, dear reader,
Thank you for this post.
Please, note that the ccNSO IANA Working Group web site is here: http://ccnso.icann.org/workinggroups/ianawg.htm
The ccNSO IANA Working Group was created by the ccNSO to adress
IANA issues. The goal of this group is to improve the service that
IANA provides to ccTLDs.
The ccNSO IANA Working Group was asked to provide input to the ccNSO on DNSSEC and signing the root :
http://ccnso.icann.org/about/minutes/ccnso-minutes-31jul07.pdf
“the IANA Working Group is asked for help in providing input to the Council on Root Zone signing from a technical perspective.”
A paper is curently being issued to respond to this demand.
The first part of this paper : “DNSSEC general background”, can be found here (draft stage) :
http://www.ccnso.icann.org/workinggroups/ccnso-iana-wg-dnssec-paper-04feb08.pdf
Update about this paper has been provided in New Delhi and can be found here:
https://delhi.icann.org/files/guillard-ccnsoianawg-dnssec_11Feb08.pdf
Portal on the IANA DNSSEC testbed is here:
https://ns.iana.org/dnssec/status.html
Announce from Ken Silva over the ccNSO members meeting about an alternative Verisign testbed is here :
https://delhi.icann.org/files/Delhi-ccNSO-12FEB08.txt
Best regards,
—
Olivier Guillard
ccNSO IANA Working Group Chair
Note: presentations provided over the last ccNSO meeting can be found here : http://www.ccnso.icann.org/meetings/newdelhi/presentations.htm