summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3130.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3130.txt')
-rw-r--r--doc/rfc/rfc3130.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc3130.txt b/doc/rfc/rfc3130.txt
new file mode 100644
index 0000000..842189a
--- /dev/null
+++ b/doc/rfc/rfc3130.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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 the
+ problem of applying digital signatures and NXT records to a zone.
+ The conclusion drawn is that there are no real problems regarding
+ memory or CPU speed when signing large zones, not even for ".com."
+ NLnet Labs has offered to work with Verisign to examine this further.
+
+ NLnet Labs is trying to define and document procedures for TLD
+ registries, registrars and registrants to properly handle actions
+ like zone-resigning and key-rollover at the root, TLD, and lower
+ levels. The outcome so far is that the DNSOP Roll Over proposal
+ seems impractical or possibly even impossible to implement at large
+ TLDs. NLnet Labs will produce a draft on an alternative KEY+SIG
+ handling scheme where SIGs are only kept in the zone where the
+ corresponding zone-KEY is located. This scheme reduces the necessary
+ actions for resigning zones from 2 levels (current zone and all
+ children) to 1 level (current zone), and for key-rollover from 3
+ levels (parent, current zone and all children) to 2 levels (parent
+ and current zone).
+
+2.2 Verisign
+
+ Verisign's registry operations and corporate components have been
+ investigating what DNSSEC means to very large zones, not just from a
+ hardware point of view, but from an institutional point of view.
+ With the service of providing delegations already commercialized,
+ they are attempting to define what it would take to provide a DNSSEC
+ service. An important issue is the parent validation of each
+ delegated zone's keys.
+
+2.3 The Foundation for Internet Infrastructure
+
+ The Foundation for Internet Infrastructure, an organization in
+ Sweden, is running a project with two parts. One part is directed at
+ the "topology" of the participants in DNSSEC, the other part of the
+ project is directed towards general development of tools.
+
+ The study is examining the administrative issues of running DNSSEC.
+ One issue is the possible 4-party interaction in the use of DNSSEC.
+ The four parties are the registry, the registrar, the registrant, and
+ the DNS operator. Of these four parties, any combination may occur
+ within one entity, such as a registrant that operates their own DNS
+ as part of their information technology department.
+
+
+
+
+
+Lewis Informational [Page 3]
+
+RFC 3130 DNSSEC Status Meeting Report June 2001
+
+
+ The other part of the study is looking at what happens in the
+ resolver. Goals include DNSSEC-enabling tools such as ISAKMPd (an
+ IPSEC key negotiation software) secure NTP4, and e-mail. Part of
+ this effort is implemented in the sigz.net experiment, information on
+ this exists at www.sigz.net.
+
+2.4 RSSAC
+
+ The RSSAC (Root Server System Advisory Committee) has come to the
+ conclusion that TSIG is worthwhile and should be deployed. There is
+ no schedule for deployment, however.
+
+ As for the rest of DNSSEC, there is a need to better understand the
+ impact of the new features before being introduced into production.
+ Currently issues regarding potential testbeds are being documented.
+ Two fundamental assumptions are that a DNSSEC testbed involving the
+ root servers is desirable and that such a testbed would allow for
+ long term testing. The latter assumption is based upon the need to
+ understand how repeated zone key validations can occur at multiple
+ independent levels of the DNS hierarchy.
+
+2.5 CAIRN
+
+ CAIRN (Collaborative Advanced Interagency Research Network) is a
+ DARPA-sponsored network for collaborative research. A funded
+ activity that involves DNSSEC is FMESHD, shorthand for Fault-Tolerant
+ Mesh of Trust in DNSSEC. The effort of this activity is to determine
+ a means of building a resolver's chain of trust when some of the DNS
+ tree is unavailable or unsecured. An early deliverable of this is an
+ extension of secure shell to retrieve keys from DNSSEC. As part of
+ this activity, the use of DNSSEC in a non-major provider zone is
+ being implemented and studied.
+
+2.6 NIST
+
+ NIST is collecting performance information regarding DNSSEC. One of
+ the fears in adopting DNSSEC is the workload it adds to existing DNS
+ machine workload. The hopes of this effort is to quantify the fear,
+ to see if it is real or imagined.
+
+ If time permits, there may be an effort to implement a zone integrity
+ checking program (implemented in Java) that will look for missteps in
+ the use of DNSSEC. Base code exists, but needs work (beyond the
+ current baseline).
+
+
+
+
+
+
+
+Lewis Informational [Page 4]
+
+RFC 3130 DNSSEC Status Meeting Report June 2001
+
+
+2.7 DISA
+
+ The U.S. Defense Information Systems Agency is providing funds to
+ have DNSSEC implemented in BIND. Of particular interest is making
+ sure that the DNSSEC specifications are correct, that BIND adheres to
+ the specifications, and that BIND is available on the operating
+ systems in use by the US Department of Defense. DISA expects that
+ every line of code developed through this effort be made publicly
+ available as part of stock BIND releases.
+
+2.8 RIPE NCC
+
+ The RIPE NCC is looking at the impact of DNSSEC on IP-registries.
+ The RIPE NCC is planning to coordinate and assist in the deployment
+ of DNSSEC. Because the RIPE NCC is the Regional Internet Registry
+ for Europe the focus will be on the deployment of DNSSEC on the
+ reverse map tree (in-addr.arpa for IPv4).
+
+2.9 ARIN
+
+ ARIN is investigating DNSSEC for use in signing its delegated zones
+ under in-addr.arpa. It participated in a dnssec workshop following
+ NANOG 20 held in Washington, DC in October, 2000. It also
+ participated in an ipv6-dnssec workshop that followed IETF 49 in San
+ Diego, California. Additionally, ARIN has stood up a server
+ dedicated to testing various dns experimentation, including dnssec
+ and carrying out limited testing.
+
+2.10 Network Associates
+
+ NAI is pressing to get the tislabs.com zone running in accordance
+ with DNSSEC. This is an example of a non-Internet service provider
+ (neither an IP transit, IP address allocation, nor a domain name
+ managing entity) making use of DNSSEC within the normal operations of
+ the Information Technology department.
+
+2.11 ip6.int. domain
+
+ The name servers authoritative for the ip6.int. domain are mostly
+ upgraded to be able to support CERT records and TSIG. Once this is
+ fully accomplished and proposals are approved, TSIG and CERT records
+ will be used. Further DNSSEC work is unknown.
+
+2.12 Topology Based Domain Search
+
+ Topology Based Domain Search (TBDS), is a DARPA funded activity
+ investigating how DNS may continue to run in disconnected parts of
+ the Internet. Topics of interest (either covered by this project, or
+
+
+
+Lewis Informational [Page 5]
+
+RFC 3130 DNSSEC Status Meeting Report June 2001
+
+
+ associated with the project) are the use of split keys, self-signed
+ zone (keys), and multiple signing algorithms. A goal is the
+ establishment of signed infrastructure zones, facilitating the
+ creation of a distributed CA for activities like IPSEC and FreeSwan.
+
+3.0 Taxonomy of efforts and What is missing
+
+ The efforts being undertaken appear to cover a broad range of work
+ areas, from large domain registries to domain name consumers. Work
+ has been progressing in the production of zones (signing, key
+ management), and is starting in the use (resolver) of DNSSEC secured
+ data.
+
+ From the discussion, there were no apparent areas lacking attention.
+ Additional input in some areas is needed however, particularly in
+ making use (applications and IT department) of DNSSEC.
+
+4.0 Questions facing DNSSEC
+
+ By the 49th IETF meeting, the most pressing question on DNSSEC is "is
+ it deployable?" From just the emphasis placed on this question, the
+ meeting generated a list of questions and made sure that either the
+ answer was known, or work was being done to address the question.
+
+4.1 Is it deployable? When?
+
+ The usual answer to this has been "not now." When is always off into
+ the future - "about a year." To get to a deployable point, a series
+ of workshops have been held since the spring of 1999.
+
+ At this point, it is becoming clearer that longer term workshops are
+ needed. In going through the motions of any workshop, the number of
+ issues raised that impact the protocol's specification is
+ diminishing, as well as implementation issues. As such, one or two
+ day workshops have been helping less and less in reaching deployment.
+
+ What is needed is to run longer term test configurations, possibly
+ workshops that are help in conjunction with other events and that
+ assume continuity. This will allow a better assessment of the issues
+ that involve the passage of time - expirations on key validations,
+ etc.
+
+ As was noted in section 1.1, and touched on in section 2, one
+ component of DNSSEC, TSIG, is more advanced that the others. Use of
+ TSIG to protect zone transfers is already matured to the "really good
+ idea to do stage" even if other elements of DNSSEC are not. Using
+ TSIG to protect traffic between local resolver and their "default"
+ recursive name server still needs more work, however.
+
+
+
+Lewis Informational [Page 6]
+
+RFC 3130 DNSSEC Status Meeting Report June 2001
+
+
+4.2 Does DNSSEC work? Is it the right approach?
+
+ Currently there is a lot of effort into making the specification as
+ proposed work. There is some effort in assessing the specification
+ at this point, particularly the value of the NXT records and possible
+ replacements of it.
+
+ There seems little question on value of the KEY and SIG records.
+ There is some research still needed on KEY validation across zone
+ boundaries. Such work is at least scheduled.
+
+4.3 How will client software make use of DNSSEC?
+
+ There are a number of efforts to take existing applications and have
+ them make direct use of DNSSEC to carry out their functions. One
+ such example is secure shell.
+
+ When or whether DNSSEC will be understood in the (using POSIX-like
+ terms) operating systems "gethostbyname" and similar routines has not
+ been addressed.
+
+4.4 What are the remaining issues?
+
+ There are still a few protocol issues. The NXT resource record is
+ designed to provide a means to authentically deny data exists. The
+ problem is that the solution proposed may be worse than the problem,
+ in the eyes of some. There is an alternative proposal, the NO
+ resource record, under consideration in the DNSEXT working group. At
+ the present time, the DNSEXT working is considering the following
+ question: Is there a need to authentically deny existence of data, if
+ so, which is better, NXT (being incumbent) or NO?
+
+ Another less defined issue is the mechanism for parent validation of
+ children signatures. Although the protocol elements of this are
+ becoming settled, the operational considerations are not, as
+ evidenced by work mentioned in section 2. DNSSEC interactions have
+ also been referenced in discussions over a standard registry-
+ registrar protocol.
+
+5.0 Progressing to Draft Standard
+
+ The IETF goal for DNSSEC is to progress the documents through the
+ standards track [RFC 2026]. Currently, RFC 2535 is the second
+ iteration at the Proposed standard level. There is a need to cycle
+ through Proposed once more. Following this, the next goal is Draft.
+
+
+
+
+
+
+Lewis Informational [Page 7]
+
+RFC 3130 DNSSEC Status Meeting Report June 2001
+
+
+ To pass to the Draft Standard level, two main requirements must be
+ met. There must be two or more interoperable implementations. There
+ must also be sufficient successful operational experience.
+
+5.1 Revision of RFC 2535 via DNSEXT
+
+ DNSEXT will soon begin a rewrite of the RFC 2535 specification (and
+ its support documents), rolling in updates and clarifications based
+ upon implementation and testing experience.
+
+5.2 Operations document(s) via DNSOP
+
+ DNSOP will continue to be the forum for operations documents based
+ upon DNSSEC activity. There is a need for the community to provide
+ more documents to this group.
+
+5.3 Interoperability
+
+ Demonstrating interoperability of DNSSEC, meaning the interaction of
+ two different implementations when performing DNSSEC work, poses an
+ issue because, to date, only BIND is seriously being fitted with
+ DNSSEC. There are other partial implementations of DNSSEC
+ functionality, so the potential for partial interoperability
+ demonstrations may exist.
+
+ During the meeting, it was realized that given goals stated, a second
+ DNSSEC implementation is needed in 18 months. Various folks in the
+ room mentioned that they would begin see what could be done about
+ this.
+
+6.0 Acknowledgements
+
+ The following people attended the meeting and/or provided text for
+ this report (in no particular order): Mark Kosters (Network
+ Solutions), Patrik Faltstrom (Cisco), Ted Lindgreen and Miek Gieben
+ (NLnet Labs), Jaap Akerhuis (SIDN), Olaf Kolkmann (RIPE NCC), Bill
+ Manning and Dan Massey (ISI), Martin Fredriksson, Hakan Olsson and
+ Jakob Schlyter (Carlstedt Research & Technology), Doug Montgomery and
+ Scott Rose (NIST), Johan Ihren and Lars-Johan Liman (Autonomica),
+ Brian Wellington (Nominum), Kevin Meynell (CENTR), Ed Lewis and
+ Olafur Gudmundsson (NAI Labs).
+
+7.0 IANA Considerations
+
+ This document does not involve assigned numbers in any way.
+
+
+
+
+
+
+Lewis Informational [Page 8]
+
+RFC 3130 DNSSEC Status Meeting Report June 2001
+
+
+8.0 Security Considerations
+
+ This document, although a discussion of security enhancements to the
+ DNS, does not itself impact security. Where security issues arise,
+ they will be discussed in the Security Considerations of the
+ appropriate document.
+
+9.0 References
+
+ The text of any RFC may be retrieved by a web browser by requesting
+ the URL: ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt, where "wxyz" is
+ the number of the RFC.
+
+ [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", July 1997.
+
+ [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+ March 1999.
+
+ [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
+ the Domain Name System", March 1999.
+
+ [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", May 2000.
+
+ [RFC 3007] Wellington, B., "Secure Domain Name System Dynamic
+ Update", November 2000.
+
+ [RFC 3008] Wellington, B., "Domain Name System Security Signing
+ Authority", November 2000.
+
+10.0 Editor's Address
+
+ Edward Lewis
+ 3060 Washington Rd (Rte 97)
+ Glenwood, MD 21738
+
+ Phone: +1(443)259-2352
+ EMail: lewis@tislabs.com
+
+
+
+
+
+
+
+
+Lewis Informational [Page 9]
+
+RFC 3130 DNSSEC Status Meeting Report June 2001
+
+
+11.0 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis Informational [Page 10]
+