tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4035

 Errata 
Proposed STD
Pages: 53
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DNSEXT

Protocol Modifications for the DNS Security Extensions

Part 1 of 3, p. 1 to 19
None       Next RFC Part

Obsoletes:    2535    3008    3090    3445    3655    3658    3755    3757    3845
Updates:    1034    1035    2136    2181    2308    3225    3597    3226
Updated by:    4470    6014    6840


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
       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.

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
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

Top      ToC       Page 6 
   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].

   An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
   add no value and would create an infinite loop in the signing
   process.

   The NS RRset that appears at the zone apex name MUST be signed, but
   the NS RRsets that appear at delegation points (that is, the NS
   RRsets in the parent zone that delegate the name to the child zone's
   name servers) MUST NOT be signed.  Glue address RRsets associated
   with delegations MUST NOT be signed.

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset
   located at the delegating parent (if any).

2.3.  Including NSEC RRs in a Zone

   Each owner name in the zone that has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record.  The
   format of NSEC RRs and the process for constructing the NSEC RR for a
   given name is described in [RFC4034].

   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
   value field in the zone SOA RR.

   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
   RRset at any particular owner name.  That is, the signing process
   MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
   the owner name of any RRset before the zone was signed.  The main
   reasons for this are a desire for namespace consistency between
   signed and unsigned versions of the same zone and a desire to reduce
   the risk of response inconsistency in security oblivious recursive
   name servers.

   The type bitmap of every NSEC resource record in a signed zone MUST
   indicate the presence of both the NSEC record itself and its
   corresponding RRSIG record.

   The difference between the set of owner names that require RRSIG
   records and the set of owner names that require NSEC records is
   subtle and worth highlighting.  RRSIG records are present at the
   owner names of all authoritative RRsets.  NSEC records are present at
   the owner names of all names for which the signed zone is
   authoritative and also at the owner names of delegations from the

Top      ToC       Page 7 
   signed zone to its children.  Neither NSEC nor RRSIG records are
   present (in the parent zone) at the owner names of glue address
   RRsets.  Note, however, that this distinction is for the most part
   visible only during the zone signing process, as NSEC RRsets are
   authoritative data and are therefore signed.  Thus, any owner name
   that has an NSEC RRset will have RRSIG RRs as well in the signed
   zone.

   The bitmap for the NSEC RR at a delegation point requires special
   attention.  Bits corresponding to the delegation NS RRset and any
   RRsets for which the parent zone has authoritative data MUST be set;
   bits corresponding to any non-NS RRset for which the parent is not
   authoritative MUST be clear.

2.4.  Including DS RRs in a Zone

   The DS resource record establishes authentication chains between DNS
   zones.  A DS RRset SHOULD be present at a delegation point when the
   child zone is signed.  The DS RRset MAY contain multiple records,
   each referencing a public key in the child zone used to verify the
   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS
   RRsets MUST NOT appear at a zone's apex.

   A DS RR SHOULD point to a DNSKEY RR that is present in the child's
   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
   by the corresponding private key.  DS RRs that fail to meet these
   conditions are not useful for validation, but because the DS RR and
   its corresponding DNSKEY RR are in different zones, and because the
   DNS is only loosely consistent, temporary mismatches can occur.

   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
   (that is, the NS RRset from the same zone containing the DS RRset).

   Construction of a DS RR requires knowledge of the corresponding
   DNSKEY RR in the child zone, which implies communication between the
   child and parent zones.  This communication is an operational matter
   not covered by this document.

2.5.  Changes to the CNAME Resource Record

   If a CNAME RRset is present at a name in a signed zone, appropriate
   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
   name for secure dynamic update purposes is also allowed ([RFC3007]).
   Other types MUST NOT be present at that name.

   This is a modification to the original CNAME definition given in
   [RFC1034].  The original definition of the CNAME RR did not allow any
   other types to coexist with a CNAME record, but a signed zone

Top      ToC       Page 8 
   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
   this conflict, this specification modifies the definition of the
   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.

2.6.  DNSSEC RR Types Appearing at Zone Cuts

   DNSSEC introduced two new RR types that are unusual in that they can
   appear at the parental side of a zone cut.  At the parental side of a
   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
   the owner name.  A DS RR could also be present if the zone being
   delegated is signed and seeks to have a chain of authentication to
   the parent zone.  This is an exception to the original DNS
   specification ([RFC1034]), which states that only NS RRsets could
   appear at the parental side of a zone cut.

   This specification updates the original DNS specification to allow
   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
   are authoritative for the parent when they appear at the parent side
   of a zone cut.

2.7.  Example of a Secure Zone

   Appendix A shows a complete example of a small signed zone.

3.  Serving

   This section describes the behavior of entities that include
   security-aware name server functions.  In many cases such functions
   will be part of a security-aware recursive name server, but a
   security-aware authoritative name server has some of the same
   requirements.  Functions specific to security-aware recursive name
   servers are described in Section 3.2; functions specific to
   authoritative servers are described in Section 3.1.

   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
   are as used in [RFC1034].

   A security-aware name server MUST support the EDNS0 ([RFC2671])
   message size extension, MUST support a message size of at least 1220
   octets, and SHOULD support a message size of 4000 octets.  As IPv6
   packets can only be fragmented by the source host, a security aware
   name server SHOULD take steps to ensure that UDP datagrams it
   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
   and [RFC3226] for further discussion of packet size and fragmentation
   issues.

Top      ToC       Page 9 
   A security-aware name server that receives a DNS query that does not
   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
   MUST NOT perform any of the additional processing described below.
   Because the DS RR type has the peculiar property of only existing in
   the parent zone at delegation points, DS RRs always require some
   special processing, as described in Section 3.1.4.1.

   Security aware name servers that receive explicit queries for
   security RR types that match the content of more than one zone that
   it serves (for example, NSEC and RRSIG RRs above and below a
   delegation point where the server is authoritative for both zones)
   should behave self-consistently.  As long as the response is always
   consistent for each query to the name server, the name server MAY
   return one of the following:

   o  The above-delegation RRsets.
   o  The below-delegation RRsets.
   o  Both above and below-delegation RRsets.
   o  Empty answer section (no records).
   o  Some other response.
   o  An error.

   DNSSEC allocates two new bits in the DNS message header: the CD
   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
   is controlled by resolvers; a security-aware name server MUST copy
   the CD bit from a query into the corresponding response.  The AD bit
   is controlled by name servers; a security-aware name server MUST
   ignore the setting of the AD bit in queries.  See Sections 3.1.6,
   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.

   A security aware name server that synthesizes CNAME RRs from DNAME
   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
   synthesized CNAME RRs.

3.1.  Authoritative Name Servers

   Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
   pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
   server for a signed zone MUST include additional RRSIG, NSEC, and DS
   RRs, according to the following rules:

   o  RRSIG RRs that can be used to authenticate a response MUST be
      included in the response according to the rules in Section 3.1.1.

Top      ToC       Page 10 
   o  NSEC RRs that can be used to provide authenticated denial of
      existence MUST be included in the response automatically according
      to the rules in Section 3.1.3.

   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
      be included in referrals automatically according to the rules in
      Section 3.1.4.

   These rules only apply to responses where the semantics convey
   information about the presence or absence of resource records.  That
   is, these rules are not intended to rule out responses such as RCODE
   4 ("Not Implemented") or RCODE 5 ("Refused").

   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
   discusses zone transfer requirements.

3.1.1.  Including RRSIG RRs in a Response

   When responding to a query that has the DO bit set, a security-aware
   authoritative name server SHOULD attempt to send RRSIG RRs that a
   security-aware resolver can use to authenticate the RRsets in the
   response.  A name server SHOULD make every attempt to keep the RRset
   and its associated RRSIG(s) together in a response.  Inclusion of
   RRSIG RRs in a response is subject to the following rules:

   o  When placing a signed RRset in the Answer section, the name server
      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
      RRs have a higher priority for inclusion than any other RRsets
      that may have to be included.  If space does not permit inclusion
      of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Authority section, the name
      server MUST also place its RRSIG RRs in the Authority section.
      The RRSIG RRs have a higher priority for inclusion than any other
      RRsets that may have to be included.  If space does not permit
      inclusion of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Additional section, the name
      server MUST also place its RRSIG RRs in the Additional section.
      If space does not permit inclusion of both the RRset and its
      associated RRSIG RRs, the name server MAY retain the RRset while
      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
      set the TC bit solely because these RRSIG RRs didn't fit.

Top      ToC       Page 11 
3.1.2.  Including DNSKEY RRs in a Response

   When responding to a query that has the DO bit set and that requests
   the SOA or NS RRs at the apex of a signed zone, a security-aware
   authoritative name server for that zone MAY return the zone apex
   DNSKEY RRset in the Additional section.  In this situation, the
   DNSKEY RRset and associated RRSIG RRs have lower priority than does
   any other information that would be placed in the additional section.
   The name server SHOULD NOT include the DNSKEY RRset unless there is
   enough space in the response message for both the DNSKEY RRset and
   its associated RRSIG RR(s).  If there is not enough space to include
   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
   NOT set the TC bit solely because these RRs didn't fit (see Section
   3.1.1).

3.1.3.  Including NSEC RRs in a Response

   When responding to a query that has the DO bit set, a security-aware
   authoritative name server for a signed zone MUST include NSEC RRs in
   each of the following cases:

   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
      but does not contain any RRsets that exactly match <SNAME, SCLASS,
      STYPE>.

   Name Error: The zone does not contain any RRsets that match <SNAME,
      SCLASS> either exactly or via wildcard name expansion.

   Wildcard Answer: The zone does not contain any RRsets that exactly
      match <SNAME, SCLASS> but does contain an RRset that matches
      <SNAME, SCLASS, STYPE> via wildcard name expansion.

   Wildcard No Data: The zone does not contain any RRsets that exactly
      match <SNAME, SCLASS> and does contain one or more RRsets that
      match <SNAME, SCLASS> via wildcard name expansion, but does not
      contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
      name expansion.

   In each of these cases, the name server includes NSEC RRs in the
   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
   not present in the zone and that the response that the name server is
   returning is correct given the data in the zone.

Top      ToC       Page 12 
3.1.3.1.  Including NSEC RRs: No Data Response

   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
   include the NSEC RR for <SNAME, SCLASS> along with its associated
   RRSIG RR(s) in the Authority section of the response (see Section
   3.1.1).  If space does not permit inclusion of the NSEC RR or its
   associated RRSIG RR(s), the name server MUST set the TC bit (see
   Section 3.1.1).

   Since the search name exists, wildcard name expansion does not apply
   to this query, and a single signed NSEC RR suffices to prove that the
   requested RR type does not exist.

3.1.3.2.  Including NSEC RRs: Name Error Response

   If the zone does not contain any RRsets matching <SNAME, SCLASS>
   either exactly or via wildcard name expansion, then the name server
   MUST include the following NSEC RRs in the Authority section, along
   with their associated RRSIG RRs:

   o  An NSEC RR proving that there is no exact match for <SNAME,
      SCLASS>.

   o  An NSEC RR proving that the zone contains no RRsets that would
      match <SNAME, SCLASS> via wildcard name expansion.

   In some cases, a single NSEC RR may prove both of these points.  If
   it does, the name server SHOULD only include the NSEC RR and its
   RRSIG RR(s) once in the Authority section.

   If space does not permit inclusion of these NSEC and RRSIG RRs, the
   name server MUST set the TC bit (see Section 3.1.1).

   The owner names of these NSEC and RRSIG RRs are not subject to
   wildcard name expansion when these RRs are included in the Authority
   section of the response.

   Note that this form of response includes cases in which SNAME
   corresponds to an empty non-terminal name within the zone (a name
   that is not the owner name for any RRset but that is the parent name
   of one or more RRsets).

3.1.3.3.  Including NSEC RRs: Wildcard Answer Response

   If the zone does not contain any RRsets that exactly match <SNAME,
   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
   via wildcard name expansion, the name server MUST include the

Top      ToC       Page 13 
   wildcard-expanded answer and the corresponding wildcard-expanded
   RRSIG RRs in the Answer section and MUST include in the Authority
   section an NSEC RR and associated RRSIG RR(s) proving that the zone
   does not contain a closer match for <SNAME, SCLASS>.  If space does
   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
   server MUST set the TC bit (see Section 3.1.1).

3.1.3.4.  Including NSEC RRs: Wildcard No Data Response

   This case is a combination of the previous cases.  The zone does not
   contain an exact match for <SNAME, SCLASS>, and although the zone
   does contain RRsets that match <SNAME, SCLASS> via wildcard
   expansion, none of those RRsets matches STYPE.  The name server MUST
   include the following NSEC RRs in the Authority section, along with
   their associated RRSIG RRs:

   o  An NSEC RR proving that there are no RRsets matching STYPE at the
      wildcard owner name that matched <SNAME, SCLASS> via wildcard
      expansion.

   o  An NSEC RR proving that there are no RRsets in the zone that would
      have been a closer match for <SNAME, SCLASS>.

   In some cases, a single NSEC RR may prove both of these points.  If
   it does, the name server SHOULD only include the NSEC RR and its
   RRSIG RR(s) once in the Authority section.

   The owner names of these NSEC and RRSIG RRs are not subject to
   wildcard name expansion when these RRs are included in the Authority
   section of the response.

   If space does not permit inclusion of these NSEC and RRSIG RRs, the
   name server MUST set the TC bit (see Section 3.1.1).

3.1.3.5.  Finding the Right NSEC RRs

   As explained above, there are several situations in which a
   security-aware authoritative name server has to locate an NSEC RR
   that proves that no RRsets matching a particular SNAME exist.
   Locating such an NSEC RR within an authoritative zone is relatively
   simple, at least in concept.  The following discussion assumes that
   the name server is authoritative for the zone that would have held
   the non-existent RRsets matching SNAME.  The algorithm below is
   written for clarity, not for efficiency.

   To find the NSEC that proves that no RRsets matching name N exist in
   the zone Z that would have held them, construct a sequence, S,
   consisting of the owner names of every RRset in Z, sorted into

Top      ToC       Page 14 
   canonical order ([RFC4034]), with no duplicate names.  Find the name
   M that would have immediately preceded N in S if any RRsets with
   owner name N had existed.  M is the owner name of the NSEC RR that
   proves that no RRsets exist with owner name N.

   The algorithm for finding the NSEC RR that proves that a given name
   is not covered by any applicable wildcard is similar but requires an
   extra step.  More precisely, the algorithm for finding the NSEC
   proving that no RRsets exist with the applicable wildcard name is
   precisely the same as the algorithm for finding the NSEC RR that
   proves that RRsets with any other owner name do not exist.  The part
   that's missing is a method of determining the name of the non-
   existent applicable wildcard.  In practice, this is easy, because the
   authoritative name server has already checked for the presence of
   precisely this wildcard name as part of step (1)(c) of the normal
   lookup algorithm described in Section 4.3.2 of [RFC1034].

3.1.4.  Including DS RRs in a Response

   When responding to a query that has the DO bit set, a security-aware
   authoritative name server returning a referral includes DNSSEC data
   along with the NS RRset.

   If a DS RRset is present at the delegation point, the name server
   MUST return both the DS RRset and its associated RRSIG RR(s) in the
   Authority section along with the NS RRset.

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR that proves that the DS RRset is not
   present and the NSEC RR's associated RRSIG RR(s) along with the NS
   RRset.  The name server MUST place the NS RRset before the NSEC RRset
   and its associated RRSIG RR(s).

   Including these DS, NSEC, and RRSIG RRs increases the size of
   referral messages and may cause some or all glue RRs to be omitted.
   If space does not permit inclusion of the DS or NSEC RRset and
   associated RRSIG RRs, the name server MUST set the TC bit (see
   Section 3.1.1).

3.1.4.1.  Responding to Queries for DS RRs

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a zone cut.  For example, the DS RRset for the
   delegation of "foo.example" is stored in the "example" zone rather
   than in the "foo.example" zone.  This requires special processing
   rules for both name servers and resolvers, as the name server for the
   child zone is authoritative for the name at the zone cut by the
   normal DNS rules but the child zone does not contain the DS RRset.

Top      ToC       Page 15 
   A security-aware resolver sends queries to the parent zone when
   looking for a needed DS RR at a delegation point (see Section 4.2).
   However, special rules are necessary to avoid confusing
   security-oblivious resolvers which might become involved in
   processing such a query (for example, in a network configuration that
   forces a security-aware resolver to channel its queries through a
   security-oblivious recursive name server).  The rest of this section
   describes how a security-aware name server processes DS queries in
   order to avoid this problem.

   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for the parent zone.

   o  The name server does not offer recursion.

   In all other cases, the name server either has some way of obtaining
   the DS RRset or could not have been expected to have the DS RRset
   even by the pre-DNSSEC processing rules, so the name server can
   return either the DS RRset or an error response according to the
   normal processing rules.

   If all the above conditions are met, however, the name server is
   authoritative for SNAME but cannot supply the requested RRset.  In
   this case, the name server MUST return an authoritative "no data"
   response showing that the DS RRset does not exist in the child zone's
   apex.  See Appendix B.8 for an example of such a response.

3.1.5.  Responding to Queries for Type AXFR or IXFR

   DNSSEC does not change the DNS zone transfer process.  A signed zone
   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
   records have no special meaning with respect to a zone transfer
   operation.

   An authoritative name server is not required to verify that a zone is
   properly signed before sending or accepting a zone transfer.
   However, an authoritative name server MAY choose to reject the entire
   zone transfer if the zone fails to meet any of the signing
   requirements described in Section 2.  The primary objective of a zone
   transfer is to ensure that all authoritative name servers have
   identical copies of the zone.  An authoritative name server that

Top      ToC       Page 16 
   chooses to perform its own zone validation MUST NOT selectively
   reject some RRs and accept others.

   DS RRsets appear only on the parental side of a zone cut and are
   authoritative data in the parent zone.  As with any other
   authoritative RRset, the DS RRset MUST be included in zone transfers
   of the zone in which the RRset is authoritative data.  In the case of
   the DS RRset, this is the parent zone.

   NSEC RRs appear in both the parent and child zones at a zone cut and
   are authoritative data in both the parent and child zones.  The
   parental and child NSEC RRs at a zone cut are never identical to each
   other, as the NSEC RR in the child zone's apex will always indicate
   the presence of the child zone's SOA RR whereas the parental NSEC RR
   at the zone cut will never indicate the presence of an SOA RR.  As
   with any other authoritative RRs, NSEC RRs MUST be included in zone
   transfers of the zone in which they are authoritative data.  The
   parental NSEC RR at a zone cut MUST be included in zone transfers of
   the parent zone, and the NSEC at the zone apex of the child zone MUST
   be included in zone transfers of the child zone.

   RRSIG RRs appear in both the parent and child zones at a zone cut and
   are authoritative in whichever zone contains the authoritative RRset
   for which the RRSIG RR provides the signature.  That is, the RRSIG RR
   for a DS RRset or a parental NSEC RR at a zone cut will be
   authoritative in the parent zone, and the RRSIG for any RRset in the
   child zone's apex will be authoritative in the child zone.  Parental
   and child RRSIG RRs at a zone cut will never be identical to each
   other, as the Signer's Name field of an RRSIG RR in the child zone's
   apex will indicate a DNSKEY RR in the child zone's apex whereas the
   same field of a parental RRSIG RR at the zone cut will indicate a
   DNSKEY RR in the parent zone's apex.  As with any other authoritative
   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
   which they are authoritative data.

3.1.6.  The AD and CD Bits in an Authoritative Response

   The CD and AD bits are designed for use in communication between
   security-aware resolvers and security-aware recursive name servers.
   These bits are for the most part not relevant to query processing by
   security-aware authoritative name servers.

   A security-aware name server does not perform signature validation
   for authoritative data during query processing, even when the CD bit
   is clear.  A security-aware name server SHOULD clear the CD bit when
   composing an authoritative response.

Top      ToC       Page 17 
   A security-aware name server MUST NOT set the AD bit in a response
   unless the name server considers all RRsets in the Answer and
   Authority sections of the response to be authentic.  A security-aware
   name server's local policy MAY consider data from an authoritative
   zone to be authentic without further validation.  However, the name
   server MUST NOT do so unless the name server obtained the
   authoritative zone via secure means (such as a secure zone transfer
   mechanism) and MUST NOT do so unless this behavior has been
   configured explicitly.

   A security-aware name server that supports recursion MUST follow the
   rules for the CD and AD bits given in Section 3.2 when generating a
   response that involves data obtained via recursion.

3.2.  Recursive Name Servers

   As explained in [RFC4033], a security-aware recursive name server is
   an entity that acts in both the security-aware name server and
   security-aware resolver roles.  This section uses the terms "name
   server side" and "resolver side" to refer to the code within a
   security-aware recursive name server that implements the
   security-aware name server role and the code that implements the
   security-aware resolver role, respectively.

   The resolver side follows the usual rules for caching and negative
   caching that would apply to any security-aware resolver.

3.2.1.  The DO Bit

   The resolver side of a security-aware recursive name server MUST set
   the DO bit when sending requests, regardless of the state of the DO
   bit in the initiating request received by the name server side.  If
   the DO bit in an initiating query is not set, the name server side
   MUST strip any authenticating DNSSEC RRs from the response but MUST
   NOT strip any DNSSEC RR types that the initiating query explicitly
   requested.

3.2.2.  The CD Bit

   The CD bit exists in order to allow a security-aware resolver to
   disable signature validation in a security-aware name server's
   processing of a particular query.

   The name server side MUST copy the setting of the CD bit from a query
   to the corresponding response.

   The name server side of a security-aware recursive name server MUST
   pass the state of the CD bit to the resolver side along with the rest

Top      ToC       Page 18 
   of an initiating query, so that the resolver side will know whether
   it is required to verify the response data it returns to the name
   server side.  If the CD bit is set, it indicates that the originating
   resolver is willing to perform whatever authentication its local
   policy requires.  Thus, the resolver side of the recursive name
   server need not perform authentication on the RRsets in the response.
   When the CD bit is set, the recursive name server SHOULD, if
   possible, return the requested data to the originating resolver, even
   if the recursive name server's local authentication policy would
   reject the records in question.  That is, by setting the CD bit, the
   originating resolver has indicated that it takes responsibility for
   performing its own authentication, and the recursive name server
   should not interfere.

   If the resolver side implements a BAD cache (see Section 4.7) and the
   name server side receives a query that matches an entry in the
   resolver side's BAD cache, the name server side's response depends on
   the state of the CD bit in the original query.  If the CD bit is set,
   the name server side SHOULD return the data from the BAD cache; if
   the CD bit is not set, the name server side MUST return RCODE 2
   (server failure).

   The intent of the above rule is to provide the raw data to clients
   that are capable of performing their own signature verification
   checks while protecting clients that depend on the resolver side of a
   security-aware recursive name server to perform such checks.  Several
   of the possible reasons why signature validation might fail involve
   conditions that may not apply equally to the recursive name server
   and the client that invoked it.  For example, the recursive name
   server's clock may be set incorrectly, or the client may have
   knowledge of a relevant island of security that the recursive name
   server does not share.  In such cases, "protecting" a client that is
   capable of performing its own signature validation from ever seeing
   the "bad" data does not help the client.

3.2.3.  The AD Bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic.  The name server side SHOULD set the AD bit if and only if
   the resolver side considers all RRsets in the Answer section and any
   relevant negative response RRs in the Authority section to be
   authentic.  The resolver side MUST follow the procedure described in
   Section 5 to determine whether the RRs in question are authentic.
   However, for backward compatibility, a recursive name server MAY set
   the AD bit when a response includes unsigned CNAME RRs if those CNAME

Top      ToC       Page 19 
   RRs demonstrably could have been synthesized from an authentic DNAME
   RR that is also included in the response according to the synthesis
   rules described in [RFC2672].

3.3.  Example DNSSEC Responses

   See Appendix B for example response packets.



(page 19 continued on part 2)

Next RFC Part