draft-ietf-dnsext-dnssec-protocol-01.txt

bind-3.2.

DNS Extensions                                                 R. Arends
Internet-Draft                                      Telematica Instituut
Expires: September 1, 2003                                     M. Larson
                                                                VeriSign
                                                              R. Austein
                                                                     ISC
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                           March 3, 2003


         Protocol Modifications for the DNS Security Extensions
                  draft-ietf-dnsext-dnssec-protocol-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 1, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document is part of a family of documents which describes the
   DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and protocol modifications which
   add data origin authentication and data integrity to the DNS.  This



Arends, et al.          Expires September 1, 2003               [Page 1]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   document describes the DNSSEC protocol modifications.  This document
   defines the concept of a signed zone, along with the requirements for
   serving and resolving using DNSSEC.  These techniques allow a
   security-aware resolver to authenticate both DNS resource records and
   authoritative DNS error indications.

   This document obsoletes RFC 2535 and incorporates changes from all
   updates to RFC 2535.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Background and Related Documents . . . . . . . . . . . . . .  4
   1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3   Editors' Notes . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.1 Open Technical Issues  . . . . . . . . . . . . . . . . . . .  4
   1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . .  4
   1.3.3 Typos and Minor Corrections  . . . . . . . . . . . . . . . .  5
   2.    Zone Signing . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1   Including KEY RRs in a Zone  . . . . . . . . . . . . . . . .  6
   2.2   Including SIG RRs in a Zone  . . . . . . . . . . . . . . . .  7
   2.3   Including NXT RRs in a Zone  . . . . . . . . . . . . . . . .  8
   2.4   Including DS RRs in a Zone . . . . . . . . . . . . . . . . .  8
   2.5   Changes to the CNAME Resource Record.  . . . . . . . . . . .  8
   2.6   Example of a Secure Zone . . . . . . . . . . . . . . . . . .  8
   3.    Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.1   Including SIG RRs in a Response  . . . . . . . . . . . . . . 10
   3.2   Including KEY RRs In a Response  . . . . . . . . . . . . . . 11
   3.3   Including NXT RRs In a Response  . . . . . . . . . . . . . . 11
   3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12
   3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches . 12
   3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches  . . 13
   3.4   Including DS RRs In a Response . . . . . . . . . . . . . . . 13
   3.5   Responding to Queries for DS RRs . . . . . . . . . . . . . . 13
   3.6   Responding to Queries for Type AXFR or IXFR  . . . . . . . . 15
   3.7   Setting the AD and CD Bits in a Response . . . . . . . . . . 15
   3.8   Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16
   4.    Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . 21
   4.1   Recursive Name Servers . . . . . . . . . . . . . . . . . . . 23
   4.2   Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
   5.    Authenticating DNS Responses . . . . . . . . . . . . . . . . 25
   5.1   Authenticating Referrals . . . . . . . . . . . . . . . . . . 26
   5.2   Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 27
   5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27
   5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28
   5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30
   5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31
   5.3   Authenticated Denial of Existence  . . . . . . . . . . . . . 31



Arends, et al.          Expires September 1, 2003               [Page 2]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   5.4   Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32
   5.4.2 Examples of Authenticating a Response  . . . . . . . . . . . 33
   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 34
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 35
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
         Normative References . . . . . . . . . . . . . . . . . . . . 37
         Informative References . . . . . . . . . . . . . . . . . . . 38
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
   A.    Algorithm For Handling Wildcard Expansion  . . . . . . . . . 40
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 41








































Arends, et al.          Expires September 1, 2003               [Page 3]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


1. Introduction

   The DNS Security Extensions (DNSSEC) modify several aspects of the
   DNS protocol.  Section 2 defines the concept of a signed zone and
   lists the requirements for zone signing.  Section 3 describes the
   modifications to authoritative name server behavior necessary to
   handle signed zones.  Section 4 describes the behavior of entities
   which include security-aware resolver functions Finally, Section 5
   defines how to use DNSSEC RRs to authenticate a response.

1.1 Background and Related Documents

   The reader is assumed to be familiar with the basic DNS concepts
   described in RFC1034 [1] and RFC1035 [2].

   This document is part of a family of documents which define the DNS
   security extensions (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and protocol modifications which
   add data origin authentication and data integrity to the DNS.  An
   introduction to DNSSEC and definition of common terms can be found in
   [9].  A definition of the DNSSEC resource records can be found in
   [10].  This document defines the DNSSEC protocol modifications.

1.2 Reserved Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.  [4].

1.3 Editors' Notes

1.3.1 Open Technical Issues

   Use of NXT RRs throughout this document set will have to be modified
   if DNSSEC-Opt-In [11] becomes part of DNSSEC.  The use of the NXT
   record requires input from the working group.  This text describes
   the NXT record as it was defined in RFC 2535, and substantial
   portions of this document would need to be updated to incorporate
   opt-in.  The updates will be made if the WG adopts opt-in.

   Use of the AD bit requires input from the working group.  Since the
   AD bit usage is not resolved, this text attempts to capture current
   ideas and drafts, but further input from the working group is
   required.

1.3.2 Technical Changes or Corrections

   Please report technical corrections to [e-mail].



Arends, et al.          Expires September 1, 2003               [Page 4]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   To assist the editors, please indicate the text in error and point
   out the RFC that defines the correct behavior.  For a technical
   change where no RFC that defines the correct behavior, or if there's
   more than one applicable RFC and the definitions conflict, please
   post the issue to namedroppers.

   An example correction to dnssec-editors might be: Page X says
   "DNSSEC RRs SHOULD be automatically returned in responses."  This was
   true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
   DNSSEC RR types MUST NOT be included in responses unless the resolver
   indicated support for DNSSEC.

1.3.3 Typos and Minor Corrections

   Please report any typos corrections to [e-mail].
   To assist the editors, please provide enough context for us to find
   the incorrect text quickly.

   An example message to dnssec-editors might be: page X says "the
   DNSSEC standard has been in development for over 1 years".   It
   should read "over 10 years".






























Arends, et al.          Expires September 1, 2003               [Page 5]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


2. Zone Signing

   DNSSEC defines the concept of a signed zone.  A signed zone includes
   KEY, SIG, NXT and (optionally) DS records according to the rules
   specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4,
   respectively.  Any zone which does not include these records
   according to the rules in this section must be considered unsigned.

      Editors' note: Should this be "MUST be considered unsigned"?

   DNSSEC requires a change to the definition of the CNAME resource
   record.  Section 2.5 changes the CNAME RR to allow SIG and NXT RRs to
   appear at the same owner name as a CNAME RR.

   Section 2.6 shows a sample signed zone.

2.1 Including KEY RRs in a Zone

      Editors' note: Unresolved inconsistency between paragraphs in this
      section, regarding non-zone KEY RRs at the zone apex.  SHOULD NOT,
      or MUST NOT?

   To sign a zone, the zone's administrator generates one or more
   public/private key pairs and uses the private key(s) to sign
   authoritative RRsets in the zone.  For each private key used to
   create SIG RRs, there SHOULD be a corresponding KEY RR stored at the
   zone apex.  All KEY RRs at the zone apex MUST be zone keys.  (A zone
   key KEY RR has the Zone Key bit of the Flags RDATA field set to one.
   See Section 2.1.1 of [10].)  Zone key KEY RRs MUST appear only at the
   zone apex.

   A signed zone MUST have at least one zone key KEY RR in its apex KEY
   RRset.  The KEY RRset at the zone apex MUST be self-signed by at
   least one private key whose corresponding public key is a zone key
   stored in the apex KEY RRset.

      Editors' note: The requirement listed in this paragraph may not be
      necessary anymore, since the KEY RRset is self-signed anyway
      (because the whole zone is signed).  This is probably a pre-DS
      relic, but we spotted this a few hours before the I-D deadline and
      were too chicken to remove it on such short notice....

   Other public keys associated with other DNS operations can be stored
   in KEY RRs that are not marked as zone keys.  Non-zone key KEY RRs
   MUST NOT appear at delegation names.  Non-zone key KEY RRs also
   SHOULD NOT appear at the zone apex, because large KEY RRsets add
   processing time at resolvers.  Non-zone key KEY RRs MAY appear at any
   other name in the zone.