DNS security work began to organize as its own activity in 1993. I do not remember when the first conversations took place, but we met for the first time as a sub-group of what was then the DNS working group during the 28th IETF, November 1993, in Houston, Texas.
Today’s IETF would call that meeting a BoF, since its principal objectives were to evaluate interest and commitment, and to develop a charter for its own working group. It has been 13 years since those early days and DNS security has undergone many changes since then.
I was the chair of the DNS Security Working Group, which did not conclude until 1999. However, the conclusion of the working group did not end work on DNS security. The consensus of the participants at the time (and of the IESG, of course) was that the work should be continued more directly by DNS experts, where it has continued to this day.
Today, some people wonder whether we will ever be done with DNS security. I believe it has become a slave to changing requirements and an evolving Internet.
The DNS Security working group was first chartered in what was the Service Applications Area with Dave Crocker serving as Area Director. The November 2003 IETF reported the following summary for the DNS Working Group meeting.
The DNS Security sub-group of the DNS working group met to identify the threats, security services, and requirements of interest to the DNS. The requirements will be distributed to the mailing list for discussion until November 30, 1993. After that time, strawman proposals may be distributed until January 31, 1993. The group will evaluate all proposals with the goal of creating one proposal at the next IETF.
It was decided to create a DNS security working group. In parallel with the activities above a charter will be drafted for review and submission to the IESG.
The working group was officially chartered in March 2004 with the following description.
The Domain Name System (DNS) security working group (dnssec) will specify enhancements to the DNS protocol to protect the DNS against unauthorized modification of data and against masquerading of DNS data origin. That is, it will add data integrity and authentication capabilities to the DNS. The specific mechanism to be added to the DNS protocol will be a digital signature.
The digital signature service will be added such that the DNS resource records will be signed and, by distributing the signatures with the records, remote sites can verify the signatures and thus have confidence in the accuracy of the records received.
There are at least two issues to be explored and resolved. First, should the records be signed by the primary or secondary (or both) servers distributing the resource records, or should they be signed by the start of authority for the zone of the records. This issue is relevant since there are servers for sites that are not IP connected. Second, the mechanism with which to distribute the public keys necessary to verify the digital signatures must be identified.
Two essential assumptions have been identified. First, backward compatibility and co-existence with DNS servers and clients that do not support the proposed security services is required. Second, data in the DNS is considered public information. This latter assumption means that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group.
There are two elements of the first summary and the first charter that are important to an understanding of the history of DNS security. First, one of the greatest mistakes we made in those early days was failing to document the actual threat discussions that led to the selection of security services to be added to the DNS protocol. At the time it seemed pretty obvious and straightforward. The scope of work was limited and we estimated we would be done in about one year (an estimation that, unfortunately, has become the DNS Security mantra). In reality it would take more than two years until the first version of the work was completed, resulting in RFC2065 – Domain Name System Security Extensions by Donald Eastlake and Charlie Kaufman – being published in January1997, almost three years from when the working group was first chartered.
Failing to document the threat analysis was wrong for at least two reasons. First, security experts will tell you that adding security without understanding why is like “putting the cart before the horse.” A threat analysis provides a careful study of what is at risk and what needs to be protected. Although it is possible that the lack of this analysis could have been tolerated initially, DNS security is no longer the simple DNS extension it was once imagined it could be. Such a document would have served as an important baseline for reviewing future extensions. Second, with respect to the question of when DNS security will be done, the threat analysis would have established clear goals against which the DNS security specification could have been evaluated. Although a prologue was published in August 2004, the informational RFC3833 “Threat Analysis of the Domain Name System (DNS) by Derek Atkins and Rob Austein,” it has not served this purpose. The conclusion from RFC3833 states:
Based on the above analysis, the DNSSEC extensions do appear to solve a set of problems that do need to be solved, and are worth deploying.
The document carefully, and probably wisely, does not judge whether the solved problems were the correct problems to solve or whether the solutions are sufficient. Thus, rather than declare “success” for the DNS security work its primary role was to end the almost 10 years of repeating discussions of why the protocol does what it does. Of course, the significance of this should not be underestimated since it has facilitated more focused effort on the issues that do need attention.
The second element of the original charter worthy of special notice is the assertion that data in the DNS is public information. The extant intent of this statement was, as stated in the charter, to ensure that confidentiality and access control services were not considered by the working group, although in principal it is obvious that the information in the DNS is public. The primary purpose of the DNS is to map domain names to IP addresses to facilitate communication between two sites. If the information is not available or is inaccessible then the sites will not be able to communicate. Unfortunately, the assertion later conflicted with a business practice requirement: preventing the transfer of the entire contents of a zone.
Although the data in the DNS must be available to be useful, in ordinary circumstances the DNS protocol inherently limits how quickly any client can access all the data in a zone. If a client knew all the domains in a zone it could query for the data available for each domain individually. Since the label for each domain in a zone could be as long as 256 characters, a brute-force search of the zone for valid domains is impractical. A protocol element for transferring the entire contents of a zone is available but all popular DNS server implementations include mechanisms that restrict access to this functionality. The result is that the entire contents of a zone is frequently unavailable to most clients.
Adding DNS security added functionality that had not previously been present in the DNS. Specifically, if a client queried for a non-existent domain, the response would correctly and securely assert that the domain did not exist but, in addition, it would indicate the lexicographically next valid domain in the zone. Through repeated queries, a client could discover and download the entire contents of a zone. This feature (or mis-feature depending on your point of view) has come to be known in technical circles as “zone walking.” The requirement to prevent zone walking has become a gating factor in the deployment of DNS security, particularly with larger zones. Significant technical resources over several years have been focused on this issue. A solution that is approaching broad consensus includes the use of OPT-IN and NSEC3. A second interoperability event is scheduled for the fall of 2006. If it is successful (and all indicators are that it will be) we may see publication of the solution in early 2007.
Moving on, as we neared the end of the first version of the DNS security extensions, dynamic update was getting attention from the DNS community. RFC2065 did include limited coverage of dynamic update issues, but ultimately, the security work for dynamic update was left as a follow on activity of the DNS Security Working Group. Our charter was updated in March 1996 to include dynamic update, as well as a few other technical issues. Of particular note is the fact that the working group moved into the Security Area with Jeff Schiller as Area Director with this update to its charter.
RFC2137 – Secure Domain Name System Dynamic Update by Donald Eastlake – was published in April 1997. Along the way RFC2065 was updated according to implementation and operational experience from developers and early adopters. RFC2535 – Domain Name System Security Extensions by Donald Eastlake – was published in March 1999.
After completion of the issues outlined in the second charter, it was time once again to consider the status of the working group. There was still work to be done. The zone-walking problem had not been resolved and there was a need to provide transaction level authentication by using shared secrets and one-way hashing in the form of TSIG (transaction signature), first published as RFC2845 in May 2000. An obvious choice would have been to update the charter accordingly and press on. However, there were two other IETF changes to consider.
The DNS Security working group was part of the Security Area. At the time its charter was updated, most security work was being done in the Security Area and it was generally accepted that this was a good thing. More recently, there has been more discussion of the question of whether the protocol work was principally about security or whether security was a component of the protocol work to be done. In this regard, the core DNS security work was arguably complete. Implementations were in progress and the work to be done was either an extension or a new requirement based on operational DNS experience. When security work was a component of the protocol work to be done, as it now was with DNS security, there was some preference for the work to progress primarily with those experts. Thus, one change was a suggestion to continue the work in the Internet Area with the DNS work.
Second, at the same time, the DNS IXFR, Notification, and Dynamic Update (DNSIND) working group, which was the only DNS working group at the time, was nearing completion of its charter’s stated goals. The question under consideration was whether to create separate working groups for the ongoing work items or to create a working group to manage the work items.
In the spirit of the IETF, a few “hallway” conversations between the IESG, working group chairs, and other interested parties resulted in a proposal to create the DNS Extensions (DNSEXT) Working Group to manage DNS related work items. The DNSSEC and DNSIND working groups concluded in December 1999 and January 2000, respectively, coincident with the chartering of the DNSEXT working group.
DNS security work began anew with early deployment experiments of RFC2535 by the Swedish and Dutch top-level domain operators, NLnet Labs, and RIPE NCC. They discovered operational problems with the key exchanges between the DNS parents and children. This was one of the principal issues that resulted in a major rewrite that became three specifications – RFC4033, RFC4034, and RFC4035 – published in March 2005. Unfortunately, the zone walking problem had still not been resolved, although this time the working group committed to solving the privacy problem.
During the last few months of the rewrite a few large top-level domain registries came to realize and asserted that the non-requirement for privacy would prohibit the deployment of DNSSEC in their environment. After careful consideration of the issue, the working group believed that a solution could be added after a deployed base of the rewrite existed. Thus, rather than delay the specifications any longer they were published so the working group could lend some focus to the zone walking problem.
DNS security work continues today under the auspices of the DNSEXT working group. Updates have progressed along with some new work. Zone walking will hopefully be resolved soon. Unfortunately, we are still not done but “we will be done soon,” or so the story goes. Finally, early adopters are deploying the protocol and the DNS Security Extensions Deployment Intiative http://dnssec-deployment.org is working to encourage voluntary adoption of DNS security protocols as part of a global effort to improve the security of the Internet’s naming infrastructure. We are much closer to declaring success now than we have been in the 10 years since the first specification was published.
It is worth noting that over the years there has been a shift in the type of people who have worked on DNSSEC development. It started with security people, moved to DNS protocol experts, and finally more operationally inclined experts joined the effort to get their concerns addressed. Each group had its own requirements, and the DNSSEC specification changed accordingly. DNSSEC, like all IETF protocols, is a slave to the members of the working group who have responsibility for it. Although such evolution is arguably rational, perhaps some of the past 13 years could have been spared if more of us could have been working together sooner, rather than one after another. It would be useful to analyze whether and how the IETF could have worked more efficiently. No protocol should ever take more than 13 years to be deployed.
[Editor’s note: For a more detailed technical description of DNSSEC, see the recent publications at http://ispcolumn.isoc.org ]