During the IETF 78 administrative plenary, meeting attendees enjoyed a champagne toast in recognition of the recent signing of the Domain Name System (DNS) root zone. As many have noted, that signing was a momentous occasion, marking the keystone in deployment of DNS-securing technology (DNS Security Extensions, or DNSSEC) after a long development process. It also seemed like the right moment to look to the future of the DNS, as we did via the Internet Society–sponsored panel event The DNS, Secure at 27: What Next? while also kicking off a process for collecting and understanding the long and involved history of DNSSEC itself.
The DNS, Secure at 27: What Next?
On 27 July 2010, the Internet Society convened a panel of experts to talk about the DNS and to give insight into the state of the DNS’s overall security. In addition to the work they do in their day jobs—involving developing, deploying, and operating the DNS and related technologies—the panellists have each been involved in IETF activities as contributors, working group (WG) chairs, and Internet Engineering Steering Group and Internet Architecture Board members. Patrik Fältström, Barry Leiba, Lars-Johan Liman, and Danny McPherson have seen DNS technology issues from all angles. While their comments on the security of DNS are reported elsewhere (see “DNSSEC Doesn’t Mitigate All DNS Threats,” page 8), the panel discussion itself first highlighted a number of ways the DNS has become more than a host name/number lookup system and then emphasized that it will continue to evolve.
By many of the metrics for protocol success that the IAB has cited in RFC 5218: What Makes for a Successful Protocol? the DNS is a successful protocol. It met a real need, it has allowed incremental deployment, it has had freely available code sources, and it has been openly maintained through IETF processes (such as the DNSOPS WG) for years. Furthermore, it has demonstrated its extensibility (through new uses) and its scalability (with tens of millions of domain names registered across all top-level domains); and with DNSSEC in place, threats are being mitigated.
The panellists said the DNS is a little hard to position in the layer model of protocol design. Lars-Johan said the DNS is the glue between the transportation and application layers and that much of our use of the Internet (through applications and services) would simply stop without it. With its global footprint, it has become the go-to infrastructure for services that share some need for resource lookup.
Patrik said that by storing materials in the DNS, which is now even more trustworthy, the DNS can be used for bootstrapping other infrastructure when DNSSEC is deployed.
Barry outlined a case in point: the work of the DKIM (DomainKeys Identified Mail) is using aspects of the DNS to let domains publish (in the DNS) information about their practices in applying signatures to email and to take responsibility, using digital signatures, for having taken part in the transmission of an email. By storing this information in the DNS, the DNS becomes a critical component in the process of receiving (not just sending) email.
To be successful in such approaches, Patrik said, it’s sometimes important to store a pointer to data (not the data itself): the DNS infrastructure for any given zone is likely administered separately from the dependent application using it to make data available, and sometimes the referenced data is larger than would reasonably be stored in a DNS record. It’s important to align administrative responsibility and data characteristics to be consistent with the DNS’s own architecture and expectations.
Lars-Johan emphasized the same point, saying that even though the DNS can hold a lot of data across its namespace, hierarchy is important. For example, caching is important for keeping stress off higher levels. If you’re going to use the DNS to store some application data, it is imperative to ensure that your applications’ data needs—and data reference needs—fit into the DNS model.
Panellists also discussed the importance of considering operational realities in order to ensure successful protocol extensions. Sometimes, designs that make perfect sense mathematically turn out to be operationally unsupportable. A case in point involved DNS bit string labels (RFC 2673), which worked well in theory but were too complex to consider deploying extensively in operational practice. That case underscores the need to design, conduct test deployments, and consider operational realities before committing to full-scale standardization and deployment. The ability to step back and reevaluate is an important part of overall successful protocol development and evolution.
The DNSSEC History Project
Along those lines, the signing of the DNS root also inspired an effort to take a step back and consider the long history of DNSSEC itself. Steve Crocker observed that the history of DNSSEC has been a very long arc, featuring work by a great number of people; false starts; facing technical, operational, and political challenges; and enduring a long hard march to success.
In July 2010, the DNSSEC History Project wiki was established (https://wiki.tools.isoc.org/DNSSEC_History_Project). The aim of the project is to collect information—in the forms of anecdotes, design documents, observations, and other contributions—from everyone who has material to share. Please do have a look at the wiki and contribute where you can.
Currently, some of the areas of observation are:
- Determination of the need: What drove the work?
- Technical design: What were the key design goals and how were they addressed? What were the alternatives?
- Government planning: R&D and policies
- Implementation and testing cycle: Bake-offs and other field events
- Public and policy-awareness events and activities
- Controversies
- Friction in deployment: Inertia, business cases
- Vendor view
The intention of the project is to collect as much raw material as possible, with a view to being able to abstract some coherent lessons learned. These will be important lessons for all protocol development, not just for the DNS or DNSSEC: many of the same hurdles are faced by other broad-scale technologies.
A Single Moment in a Long History
The champagne at the administrative plenary may have been but a single moment, but it was a good vantage point from which to consider the past as it illuminates the future for the DNS in general and DNSSEC in particular.
This article was posted on 31 January 2011