rfc4035.txt

非常好的dns解析软件

Network Working Group                                          R. Arends
Request for Comments: 4035                          Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
           3755, 3757, 3845                                          ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign
Category: Standards Track                                      D. Massey
                                               Colorado State University
                                                                 S. Rose
                                                                    NIST
                                                              March 2005


         Protocol Modifications for the DNS Security Extensions

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document is part of a family of documents that describe the DNS
   Security Extensions (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and protocol modifications that
   add data origin authentication and data integrity to the DNS.  This
   document describes the DNSSEC protocol modifications.  This document
   defines the concept of a signed zone, along with the requirements for
   serving and resolving by 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.










Arends, et al.              Standards Track                     [Page 1]

RFC 4035             DNSSEC Protocol Modifications            March 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Background and Related Documents . . . . . . . . . . . .  4
       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4
   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.  Including DNSKEY RRs in a Zone . . . . . . . . . . . . .  5
       2.2.  Including RRSIG RRs in a Zone  . . . . . . . . . . . . .  5
       2.3.  Including NSEC RRs in a Zone . . . . . . . . . . . . . .  6
       2.4.  Including DS RRs in a Zone . . . . . . . . . . . . . . .  7
       2.5.  Changes to the CNAME Resource Record.  . . . . . . . . .  7
       2.6.  DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . .  8
       2.7.  Example of a Secure Zone . . . . . . . . . . . . . . . .  8
   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9
             3.1.1.  Including RRSIG RRs in a Response  . . . . . . . 10
             3.1.2.  Including DNSKEY RRs in a Response . . . . . . . 11
             3.1.3.  Including NSEC RRs in a Response . . . . . . . . 11
             3.1.4.  Including DS RRs in a Response . . . . . . . . . 14
             3.1.5.  Responding to Queries for Type AXFR or IXFR  . . 15
             3.1.6.  The AD and CD Bits in an Authoritative Response. 16
       3.2.  Recursive Name Servers . . . . . . . . . . . . . . . . . 17
             3.2.1.  The DO Bit . . . . . . . . . . . . . . . . . . . 17
             3.2.2.  The CD Bit . . . . . . . . . . . . . . . . . . . 17
             3.2.3.  The AD Bit . . . . . . . . . . . . . . . . . . . 18
       3.3.  Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
       4.1.  EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
       4.2.  Signature Verification Support . . . . . . . . . . . . . 19
       4.3.  Determining Security Status of Data  . . . . . . . . . . 20
       4.4.  Configured Trust Anchors . . . . . . . . . . . . . . . . 21
       4.5.  Response Caching . . . . . . . . . . . . . . . . . . . . 21
       4.6.  Handling of the CD and AD Bits . . . . . . . . . . . . . 22
       4.7.  Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
       4.8.  Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
       4.9.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
             4.9.1.  Handling of the DO Bit . . . . . . . . . . . . . 24
             4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24
             4.9.3.  Handling of the AD Bit . . . . . . . . . . . . . 24
   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
       5.1.  Special Considerations for Islands of Security . . . . . 26
       5.2.  Authenticating Referrals . . . . . . . . . . . . . . . . 26
       5.3.  Authenticating an RRset with an RRSIG RR . . . . . . . . 28
             5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28
             5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29
             5.3.3.  Checking the Signature . . . . . . . . . . . . . 31
             5.3.4.  Authenticating a Wildcard Expanded RRset
                     Positive Response. . . . . . . . . . . . . . . . 32



Arends, et al.              Standards Track                     [Page 2]

RFC 4035             DNSSEC Protocol Modifications            March 2005


       5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32
       5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33
       5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
       9.1.  Normative References . . . . . . . . . . . . . . . . . . 34
       9.2.  Informative References . . . . . . . . . . . . . . . . . 35
   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36
   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41
       B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
       B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
       B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44
       B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44
       B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45
       B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
       B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
       B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48
   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49
       C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49
             C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49
       C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
       C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50
       C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50
       C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51
       C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
       C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
       C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53

1.  Introduction

   The DNS Security Extensions (DNSSEC) are a collection of new resource
   records and protocol modifications that add data origin
   authentication and data integrity to the DNS.  This document defines
   the DNSSEC protocol modifications.  Section 2 of this document
   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 for handling signed zones.  Section 4
   describes the behavior of entities that include security-aware
   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
   to authenticate a response.







Arends, et al.              Standards Track                     [Page 3]

RFC 4035             DNSSEC Protocol Modifications            March 2005


1.1.  Background and Related Documents

   This document is part of a family of documents defining DNSSEC that
   should be read together as a set.

   [RFC4033] contains an introduction to DNSSEC and definitions of
   common terms; the reader is assumed to be familiar with this
   document.  [RFC4033] also contains a list of other documents updated
   by and obsoleted by this document set.

   [RFC4034] defines the DNSSEC resource records.

   The reader is also assumed to be familiar with the basic DNS concepts
   described in [RFC1034], [RFC1035], and the subsequent documents that
   update them; particularly, [RFC2181] and [RFC2308].

   This document defines the DNSSEC protocol operations.

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 [RFC2119].

2.  Zone Signing

   DNSSEC introduces the concept of signed zones.  A signed zone
   includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
   Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
   according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
   respectively.  A zone that does not include these records according
   to the rules in this section is an unsigned zone.

   DNSSEC requires a change to the definition of the CNAME resource
   record ([RFC1035]).  Section 2.5 changes the CNAME RR to allow RRSIG
   and NSEC RRs to appear at the same owner name as does a CNAME RR.

   DNSSEC specifies the placement of two new RR types, NSEC and DS,
   which can be placed at the parental side of a zone cut (that is, at a
   delegation point).  This is an exception to the general prohibition
   against putting data in the parent zone at a zone cut.  Section 2.6
   describes this change.









Arends, et al.              Standards Track                     [Page 4]

RFC 4035             DNSSEC Protocol Modifications            March 2005


2.1.  Including DNSKEY RRs in a Zone

   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 RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
   containing the corresponding public key.  A zone key DNSKEY RR MUST
   have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
   of [RFC4034]).  Public keys associated with other DNS operations MAY
   be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
   be used to verify RRSIGs.

   If the zone administrator intends a signed zone to be usable other
   than as an island of security, the zone apex MUST contain at least
   one DNSKEY RR to act as a secure entry point into the zone.  This
   secure entry point could then be used as the target of a secure
   delegation via a corresponding DS RR in the parent zone (see
   [RFC4034]).

2.2.  Including RRSIG RRs in a Zone

   For each authoritative RRset in a signed zone, there MUST be at least
   one RRSIG record that meets the following requirements:

   o  The RRSIG owner name is equal to the RRset owner name.

   o  The RRSIG class is equal to the RRset class.

   o  The RRSIG Type Covered field is equal to the RRset type.

   o  The RRSIG Original TTL field is equal to the TTL of the RRset.

   o  The RRSIG RR's TTL is equal to the TTL of the RRset.

   o  The RRSIG Labels field is equal to the number of labels in the
      RRset owner name, not counting the null root label and not
      counting the leftmost label if it is a wildcard.

   o  The RRSIG Signer's Name field is equal to the name of the zone
      containing the RRset.

   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
      zone key DNSKEY record at the zone apex.

   The process for constructing the RRSIG RR for a given RRset is
   described in [RFC4034].  An RRset MAY have multiple RRSIG RRs
   associated with it.  Note that as RRSIG RRs are closely tied to the
   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS



Arends, et al.              Standards Track                     [Page 5]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   RR types, do not form RRsets.  In particular, the TTL values among
   RRSIG RRs with a common owner name do not follow the RRset rules
   described in [RFC2181].