Management of the DNS root zone file is a uniquely global policy problem. For the Internet to connect everyone, the root of the internet’s identifier systems must be coordinated and compatible. But who will control that coordination process? Right now, the U.S. government assumes exclusive responsibility for it. The U.S. refuses to internationalize its oversight, or to delegate it fully to ICANN. Internet users and governments in other countries are uncomfortable with U.S. unilateral control, knowing that the U.S. could, if it wanted, exploit its power over the root for political, military or economic advantage. For that reason, DNS root zone file management has been one of the most controversial issues in Internet governance.
Despite this deadlock there is hope for change. Management authority over the legacy root zone file may be contentious and divisive, but everyone agrees that the Internet should be made more secure. A newly standardized protocol, DNS Security Extensions (DNSSEC), would make the Internet's infrastructure more secure. In order to implement DNSSEC, the procedures for managing the DNS root must be systematically revised. Therein lies an opportunity. In revising the root zone management procedures, we can develop a new solution to the root zone management problem, a solution that diminishes the impact of the legacy monopoly held by the U.S. government. Over the next month we will describe the outlines of a new system for the management of a DNSSEC-enabled root. One that distributes authority more than the current method while avoiding the risks and pitfalls of an intergovernmental power sharing scheme.
Next up: What is DNSSEC, what makes it controversial?
[Editors note: The last week has been highly unusual, with a lot of attention on the web being devoted to DNSSEC. First, there was the new IAB chair talking about it, then the Heisse story which broke some news that happened at ICANN about the relationship
between VeriSign and the USG and the role of the DHS in root signing, then a reality check about DHS intention by another IAB member at Educated Guesswork, a bunch of sometimes less thought out response at /., and other blogs, and some in the security application industry questioning the usefulness of DNSSEC (and strangely expecting IGP to be defending it). Additionally, discussion picked up about technical options for root signing on some of the expert lists .
Overall, more buzz on DNSSEC than I've seen in a long time. However, in some cases, accuracy in describing what DNSSEC actually does and doesn't do, and how it works has been overshadowed by hype.
This is unfortunate because there is a lot of good material (albeit largely written for a technical audience) out there which detail DNSSEC. On the other hand, the hype demonstrates the necessity of
getting the policy issues around DNSSEC out in the open. Now, we do not claim authority in technical matters surrounding DNSSEC (look to the IETF
working group, among others for that), but we do claim to know a thing or two about Internet governance, and how Internet technology and politics often intersect. We hope this work
(with help from your comments) will shed further light on that.]
You're right; I apologize for presuming that you'd be defending DNSSEC. I inferred it from “DNSSEC will make the Internet more secure”, but ignored the “let's talk about what makes it controversial”.
I hope you can capture more than just the controversy about who deploys DNSSEC (the DHS or ICANN or the ISPs). I hope you can also manage to address:
* The alienation that seems to exist between application developers, network operators, and the IETF standards bodies, which for example caused Apple to ship a multicast DNS implementation (“Bonjour”) that leads the market and that the IETF openly competes with.
* The insularity perceived in the IETF DNS standards groups, which ostracized Daniel J. Bernstein, author of one of the top 3 DNS implementations, and excluded his voice from the standards.
* The faction of the IETF that believes that public consensus has failed, and that the way ahead is to have for-proft entities work with vendors to dictate standards.
* The total lack of consensus among developers, security practitioners, standards groups, and vendors about what the Internet's security problems are and where they're best solved (a hint: most security people would tell you that the important problems are all inside Mozilla and Internet Explorer).
I think this is a very cool subject to tackle on an Internet governance blog. I just want to make sure we don't hold out the IETF (or security people, for that matter) as “protagonists” in a challenge drama.
“In order to implement DNSSEC, the procedures for managing the DNS root must be systematically revised.”
Actually, no it doesn't. All it really requires is adding a step to the process.
Rgds,
-drc
Which “one step” is that?
The step that takes the zone contents and signs it just before publication, of course. There is no need to systematically revise the root zone management process as the input to the zone signing process is the already modified zone. In reality, DNSSEC has precisely zero impact on Internet governance. The _only_ thing DNSSEC gives you is the ability to determine whether or not a set of resource records in a zone has been modified between when it was published on the authoritative server and when a client (typically a caching resolver) has fetched it.
Rgds,
-drc
Thanks for the comments. We're thrilled to see the broader interest in Internet governance issues. While I don't think we'll get to it in this serial blog, you're right, any complete historical examination of DNSSEC would have to acknowledge the tension between security application developers and “DNS traditionalists.” It's been pretty evident in evolution of this standard. As for DNSEXT being a group closed to others ideas and IETF being a model of open standards development, I'll leave that to further empirical examination. BTW, keep up the good blog work, looking forward to more diagrams!
Who bears the costs for that? Have you been following the DLV and off-tree-signing debates? Several of the DNSSEC architects are planning on setting up alternate roots because of the Internet Governance impact of DNSSE.
I think you're oversimplifying this a bit.
>The step that takes the zone contents and signs it
>just before publication, of course.
Is that “one step?” Even if it is so considered, who controls the keys? how are they managed?
If you define “root zone management process” narrowly as simply “what happens once you have a signed zone” then of course you can view it as little changing. If you define it more broadly (and accurately imho) as the preparation of the zone file for publication, then lots will change.
“Who bears the cost for that?”
Assuming you're talking about the costs of signing the root, presumably the organization chosen to sign the root. You appear to be making a significant leap in assuming the costs for signing the root will cause root management procedures to be “systematically revised”. I see no evidence to justify such a leap. DNSSEC signing need merely add an additional step to the DNS root management procedures.
“Have you been following the DLV and off-tree-signing debates?”
You might say that.
“Several of the DNSSEC architects are planning on setting up alternate roots because of the Internet Governance impact of DNSSE.[sic]”
Who are “DNSSEC architects”? I would not be surprised that some DNSSEC-knowledgable individuals are discussing setting up alterative trust hierarchies due to the political issues involved in signing the root, however this is irrelevant to the assertion that the root management procedures must be systematically revised to implement DNSSEC.
“I think you're oversimplifying this a bit”
Actually, I'm trying to reduce the hype. DNSSEC is a technical solution to a particular vulnerability in the DNS protocol specification. It is not magic pixie dust that will by itself trigger a revision, systematic or not, to root management procedures. Such revisions _may_ occur, but they are NOT required to implement DNSSEC.
Rgds,
-drc
“Is that one step?”
Conceptually speaking, yes. Technically, it may consist of multiple steps, but in terms of root management procedures, it is a single step. Output of the root modification procedure is fed to the DNSSEC signing procedure and the output of that procedure is fed to the root zone publication procedure.
“who controls the keys?”
Indeterminate at this time (at least I am unaware of any decision regarding who holds the root KSK). How is that relevant to systematic revision to the root management procedure?
“If you define it more broadly (…) as the preparation of the zone file for publication, then lots will change.”
OK, I'll bite. Define “lots”. From a technical perspective, little needs to change and there certainly is no requirement for “systematic” revision to procedures in order to implement DNSSEC. Presumably, you believe there are non-technical changes that will be required. What are they?
Rgds,
-drc
anonymous said: “who controls the keys?”
dc396 said: “Indeterminate at this time (at least I am unaware of any decision regarding who holds the root KSK). How is that relevant to systematic revision to the root management procedure?”
So is this an open question – using a single KSK or multiple KSKs for signing the root? Seems the later would make a big procedural and technical difference in root zone management.
“using a single KSK or multiple KSKs for signing the root?”
There will almost certainly be multiple KSKs (to deal with key rollover in a reasonable fashion). What I suspect you meant to ask if there will be multiple signers. There has been some discussion along these lines, but there are some technical issues that would need to be addressed (DNS response size, being one of them).
“Seems the later would make a big procedural and technical difference in root zone management.”
Not really. DNSSEC is like putting a padlock on street signs. Having multiple signers would be like having multiple padlocks. The hard bit in root zone management procedures is getting everybody to agree on what the street sign says. Putting the padlock on and turning the key (regardless of the number of padlocks) is simply an extra step.
Rgds,
-drc
“There will almost certainly be multiple KSKs (to deal with key rollover in a reasonable fashion).”
For now let's set aside the rollover issue. We can agree that you can have multiple organizations (but a technically limited number), each with a KSK, that could sign the root?
“The hard bit in root zone management procedures is getting everybody to agree on what the street sign says.”
Absolutely. This suggests that any discussion about root signing should consider a process for distributing authority over what actually signs the root zone file contents (i.e., the ZSK), not just the KSKs?