Notes from the State-Of-The-Technology: DNSSEC
RFC 3130
Document | Type |
RFC - Informational
(June 2001; No errata)
Was draft-lewis-state-of-dnssec (individual)
|
|
---|---|---|---|
Author | Edward Lewis | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3130 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group E. Lewis Request for Comments: 3130 NAI Labs Category: Informational June 2001 Notes from the State-Of-The-Technology: DNSSEC Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. 1.0 Introduction A meeting of groups involved in the development of the DNS Security Extensions (DNSSEC) was held in conjunction with the 49th IETF. The discussion covered the extent of current efforts, a discussion of what questions are being asked of DNSSEC, and what is needed by the IETF to progress the definition to the Draft Standard level. DNSSEC [RFC 2535] has been under consideration for quite a few years, with RFC 2535 being the core of the most recent definition. DNSSEC is part of the charter of two working groups, DNSEXT and DNSOP. ISC's BIND v8.2 implemented part of the specification, BIND v9 represents the first full implementation. In 1999 and 2000, more than a half dozen workshops have been held to test the concepts and the earliest versions of implementations. But to date, DNSSEC is not in common use. The current collective wisdom is that DNSSEC is 1) important, 2) a buzzword, 3) hard, 4) immature. To capture the true state of the technology and identify where work is needed, an informal gathering of groups known to be involved in DNSSEC was held in conjunction with the 49th IETF. The attendees represented NLnet Labs, The Foundation for Internet Infrastructure, RIPE NCC, ARIN, CAIRN (ISI and NAI Labs), NIST, DISA, RSSAC, Network Associates and Verisign (COM/NET/ORG TLDs). Lewis Informational [Page 1] RFC 3130 DNSSEC Status Meeting Report June 2001 The agenda of the meeting consisted of three items. Reports from each group on their current research goals were followed by a discussion of questions being asked of DNSSEC. Finally, with reaching Draft Standard status as a goal, what was needed to make this happen was considered. This report is not simply a transcript of the meeting, it is a summary. Some of the information presented here was obtained in direct contact with participants after the meeting. 1.1 What does the term "DNSSEC" mean? One of the comments made during discussions is that DNSSEC does not refer to just one monolithic technology. The term has come to refer to "toolbox" of techniques and methodologies, that when used properly can improve the integrity of the DNS. Given this observation, it can be seen that some portions of DNSSEC are evolving much more rapidly than other portions. In particular, TSIG [RFC 2845] has certainly reached a level "being deployable" for zone transfers. The following four components are considered to be part of DNSSEC. The concept of digital signature protection of DNS traffic as described in RFC 2535 and a few support documents (such as [RFC 3008]), which is designed to protect the transfer of data on an Internet scale. The concept of protecting queries and responses through the less-scalable but more efficient TSIG mechanism [RFC 2845], which has applicability to zone transfers, DHCP registrations, and other resolver to name server traffic. Secure dynamic updates [RFC 3007], by virtue of using TSIG, can be considered to be part of DNSSEC. Finally, the definition of the CERT resource record [RFC 2538] gives DNS the ability to become a distribution mechanism for security data. This definition of the components of DNSSEC is in no way definitive. To be honest, this is a somewhat artificial grouping. DNSSEC does not encompass all of the security practiced in DNS today, for example, the redefinition of when and how data is cached [RFC 2181], plays a big role in hardening the DNS system. The four elements of DNSSEC described in the previous paragraph are grouped together mostly because they do interrelate, but also they were developed at approximately the same time. 2.0 Group Reports The first part of the meeting consisted of reports of goals. From this a taxonomy of efforts has been made to see if there are gaps in the work. Lewis Informational [Page 2] RFC 3130 DNSSEC Status Meeting Report June 2001 2.1 NLnet Labs Efforts by NLnet Labs are directed towards yielding an understanding of the impact of DNSSEC on ccTLDs, specifically .de (Germany), .nl (The Netherlands), and .se (Sweden). Work to date has studied theShow full document text