Notes from the State-Of-The-Technology: DNSSEC
RFC 3130

Document Type RFC - Informational (June 2001; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html 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]
Show full document text