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.
DHS publicly acknowledges DNSSEC root signing spec
Nearly five months after the fact, DHS acknowledged widely last week the release of a draft technical specification for signing and securing the DNS Root Zone. Signing the root is considered a critical step toward the 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:
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...
