Securing the Root: A proposal for distributing signing authority

The implementation of DNSSEC and required development of a procedure to sign the DNS root zone file provides an opportunity to restructure the current political oversight exerted by the United States and achieve shared responsibility for the secure and stable operation of the Internet’s root zone. Specifically, multiple, but limited number of, non-governmental Root Key Operators (RKOs) should be responsible for generating, use and distribution of root zone key-signing keys (KSKs) and zone signing keys (ZSKs). In practice, this will require close coordination between RKO and RZM organizations in executing contractually agreed upon roles.

05.2007 Securing The Root: A Proposal For Distributing Signing Authority

[Abstract] Drafters: Brenden Kuerbis, Milton MuellerManagement of the Domain Name System (DNS) root zone file is a uniquely global policy problem. For the Internet to connect everyone, the root must be coordinated and compatible. While authority over the legacy root zone file has been contentious and divisive at times, everyone...

A2K Conference at Yale: Some Observations

I am attending the Yale Information Society Project's second Access to Knowledge (A2K) conference. There are about 150 people here. The story is that the leaders of Yale ISP are self-consciously positioning A2K as a social movement and simultaneously putting forward A2K as an overarching master frame for the entire range of communication and information policy issues. (For a broad historical background on communication-information as an integrated policy domain and the convergence of multiple issue networks, including intellectual propert-related advocacy, around the problems of digital media, see our study Reinventing Media Activism, published in 2004.)

Securing the Root: The root of the problem, creating a trust anchor(s)

Our last post explained the basics of how DNSSEC works. A security-aware resolver's ability to validate nameserver responses is accomplished by establishing an authentication chain from a known trust anchor(s) (i.e., a DNSKEY or signed DS record) to the zone which has provided the signed response. If a resolver is configured with a trust anchor(s) that exists higher in the DNS tree, e.g., the root's public key[1], it can theoretically verify any signed responses. This is because a path can always be constructed from the root to lower zones, assuming every zone in the path is signed and carries a Delegation Signer (DS) Resource Record for child zones. This architectural design highlights the critical importance of parent nameservers maintaining DS records and of signing those records to widespread deployment of DNSSEC across the Internet.

Securing the Root: What is DNSSEC, what's the controversy?

[Editor's note: Below is an overview of DNSSEC written for a non-technical audience, however, it assumes some basic knowledge of the Domain Name System (DNS) and public-key cryptography concepts. The point is to provide enough detail to allow us to understand how chosen technology and institutional design creates Internet governance dilemmas. If there is technical blunder, my apologies – by all means let me know. Clear concepts are a baseline for productive debate. And as I said previously, see the actual specifications (RFC 4033, 4034, 4035) or other reference material, e.g., Geoff Huston's article series or Ron Aithchison's work for more detailed technical explanations. Looking forward to your comments.]

What is DNSSEC?

DNSSEC is a proposed Internet standard that modifies DNS resource records and protocols to provide security for query and response transactions made between domain name resolvers and nameservers. Specifically, the security DNSSEC provides includes:

  • Integrity verification: a DNS resolver can determine that information received from a nameserver has not been tampered with in transit
  • Source authentication: a DNS resolver can determine that the information received originated from an authoritative nameserver
  • Authenticated denial of existence: a DNS resolver can verify that a particular query is unresolvable because no DNS record actually exists on the authoritative nameserver
  • Securing the Root: Introduction

    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.

    Securing the Root: Serial Blog launch

    Today, IGP launches a month-long series of blog entries on DNS security, focusing specifically on the problem of cryptographically signing the DNS root zone. We will explore some of the hidden and not-so-hidden political implications of this technical change. We will show how DNSSEC implementation, if handled properly, creates an...