GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4035

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

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

 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

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

 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.

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

 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.

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

 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.

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

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.

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

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

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

 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

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

 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.

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

 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

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

 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.

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

 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

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

 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

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

 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.

4. Resolving

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

4.1. EDNS Support

 A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
 pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
 A security-aware resolver MUST support a message size of at least
 1220 octets, SHOULD support a message size of 4000 octets, and MUST
 use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
 to advertise the message size that it is willing to accept.  A
 security-aware resolver's IP layer MUST handle fragmented UDP packets
 correctly regardless of whether any such fragmented packets were
 received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
 [RFC3226] for discussion of these requirements.

4.2. Signature Verification Support

 A security-aware resolver MUST support the signature verification
 mechanisms described in Section 5 and SHOULD apply them to every
 received response, except when:
 o  the security-aware resolver is part of a security-aware recursive
    name server, and the response is the result of recursion on behalf
    of a query received with the CD bit set;
 o  the response is the result of a query generated directly via some
    form of application interface that instructed the security-aware
    resolver not to perform validation for this query; or
 o  validation for this query has been disabled by local policy.

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

 A security-aware resolver's support for signature verification MUST
 include support for verification of wildcard owner names.
 Security-aware resolvers MAY query for missing security RRs in an
 attempt to perform validation; implementations that choose to do so
 must be aware that the answers received may not be sufficient to
 validate the original response.  For example, a zone update may have
 changed (or deleted) the desired information between the original and
 follow-up queries.
 When attempting to retrieve missing NSEC RRs that reside on the
 parental side at a zone cut, a security-aware iterative-mode resolver
 MUST query the name servers for the parent zone, not the child zone.
 When attempting to retrieve a missing DS, a security-aware
 iterative-mode resolver MUST query the name servers for the parent
 zone, not the child zone.  As explained in Section 3.1.4.1,
 security-aware name servers need to apply special processing rules to
 handle the DS RR, and in some situations the resolver may also need
 to apply special rules to locate the name servers for the parent zone
 if the resolver does not already have the parent's NS RRset.  To
 locate the parent NS RRset, the resolver can start with the
 delegation name, strip off the leftmost label, and query for an NS
 RRset by that name.  If no NS RRset is present at that name, the
 resolver then strips off the leftmost remaining label and retries the
 query for that name, repeating this process of walking up the tree
 until it either finds the NS RRset or runs out of labels.

4.3. Determining Security Status of Data

 A security-aware resolver MUST be able to determine whether it should
 expect a particular RRset to be signed.  More precisely, a
 security-aware resolver must be able to distinguish between four
 cases:
 Secure: An RRset for which the resolver is able to build a chain of
    signed DNSKEY and DS RRs from a trusted security anchor to the
    RRset.  In this case, the RRset should be signed and is subject to
    signature validation, as described above.
 Insecure: An RRset for which the resolver knows that it has no chain
    of signed DNSKEY and DS RRs from any trusted starting point to the
    RRset.  This can occur when the target RRset lies in an unsigned
    zone or in a descendent of an unsigned zone.  In this case, the
    RRset may or may not be signed, but the resolver will not be able
    to verify the signature.

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

 Bogus: An RRset for which the resolver believes that it ought to be
    able to establish a chain of trust but for which it is unable to
    do so, either due to signatures that for some reason fail to
    validate or due to missing data that the relevant DNSSEC RRs
    indicate should be present.  This case may indicate an attack but
    may also indicate a configuration error or some form of data
    corruption.
 Indeterminate: An RRset for which the resolver is not able to
    determine whether the RRset should be signed, as the resolver is
    not able to obtain the necessary DNSSEC RRs.  This can occur when
    the security-aware resolver is not able to contact security-aware
    name servers for the relevant zones.

4.4. Configured Trust Anchors

 A security-aware resolver MUST be capable of being configured with at
 least one trusted public key or DS RR and SHOULD be capable of being
 configured with multiple trusted public keys or DS RRs.  Since a
 security-aware resolver will not be able to validate signatures
 without such a configured trust anchor, the resolver SHOULD have some
 reasonably robust mechanism for obtaining such keys when it boots;
 examples of such a mechanism would be some form of non-volatile
 storage (such as a disk drive) or some form of trusted local network
 configuration mechanism.
 Note that trust anchors also cover key material that is updated in a
 secure manner.  This secure manner could be through physical media, a
 key exchange protocol, or some other out-of-band means.

4.5. Response Caching

 A security-aware resolver SHOULD cache each response as a single
 atomic entry containing the entire answer, including the named RRset
 and any associated DNSSEC RRs.  The resolver SHOULD discard the
 entire atomic entry when any of the RRs contained in it expire.  In
 most cases the appropriate cache index for the atomic entry will be
 the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
 form described in Section 3.1.3.2 the appropriate cache index will be
 the double <QNAME,QCLASS>.
 The reason for these recommendations is that, between the initial
 query and the expiration of the data from the cache, the
 authoritative data might have been changed (for example, via dynamic
 update).

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

 There are two situations for which this is relevant:
 1.  By using the RRSIG record, it is possible to deduce that an
     answer was synthesized from a wildcard.  A security-aware
     recursive name server could store this wildcard data and use it
     to generate positive responses to queries other than the name for
     which the original answer was first received.
 2.  NSEC RRs received to prove the non-existence of a name could be
     reused by a security-aware resolver to prove the non-existence of
     any name in the name range it spans.
 In theory, a resolver could use wildcards or NSEC RRs to generate
 positive and negative responses (respectively) until the TTL or
 signatures on the records in question expire.  However, it seems
 prudent for resolvers to avoid blocking new authoritative data or
 synthesizing new data on their own.  Resolvers that follow this
 recommendation will have a more consistent view of the namespace.

4.6. Handling of the CD and AD Bits

 A security-aware resolver MAY set a query's CD bit in order to
 indicate that the resolver takes responsibility for performing
 whatever authentication its local policy requires on the RRsets in
 the response.  See Section 3.2 for the effect this bit has on the
 behavior of security-aware recursive name servers.
 A security-aware resolver MUST clear the AD bit when composing query
 messages to protect against buggy name servers that blindly copy
 header bits that they do not understand from the query message to the
 response message.
 A resolver MUST disregard the meaning of the CD and AD bits in a
 response unless the response was obtained by using a secure channel
 or the resolver was specifically configured to regard the message
 header bits without using a secure channel.

4.7. Caching BAD Data

 While many validation errors will be transient, some are likely to be
 more persistent, such as those caused by administrative error
 (failure to re-sign a zone, clock skew, and so forth).  Since
 requerying will not help in these cases, validating resolvers might
 generate a significant amount of unnecessary DNS traffic as a result
 of repeated queries for RRsets with persistent validation failures.
 To prevent such unnecessary DNS traffic, security-aware resolvers MAY
 cache data with invalid signatures, with some restrictions.

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

 Conceptually, caching such data is similar to negative caching
 ([RFC2308]), except that instead of caching a valid negative
 response, the resolver is caching the fact that a particular answer
 failed to validate.  This document refers to a cache of data with
 invalid signatures as a "BAD cache".
 Resolvers that implement a BAD cache MUST take steps to prevent the
 cache from being useful as a denial-of-service attack amplifier,
 particularly the following:
 o  Since RRsets that fail to validate do not have trustworthy TTLs,
    the implementation MUST assign a TTL.  This TTL SHOULD be small,
    in order to mitigate the effect of caching the results of an
    attack.
 o  In order to prevent caching of a transient validation failure
    (which might be the result of an attack), resolvers SHOULD track
    queries that result in validation failures and SHOULD only answer
    from the BAD cache after the number of times that responses to
    queries for that particular <QNAME, QTYPE, QCLASS> have failed to
    validate exceeds a threshold value.
 Resolvers MUST NOT return RRsets from the BAD cache unless the
 resolver is not required to validate the signatures of the RRsets in
 question under the rules given in Section 4.2 of this document.  See
 Section 3.2.2 for discussion of how the responses returned by a
 security-aware recursive name server interact with a BAD cache.

4.8. Synthesized CNAMEs

 A validating security-aware resolver MUST treat the signature of a
 valid signed DNAME RR as also covering unsigned CNAME RRs that could
 have been synthesized from the DNAME RR, as described in [RFC2672],
 at least to the extent of not rejecting a response message solely
 because it contains such CNAME RRs.  The resolver MAY retain such
 CNAME RRs in its cache or in the answers it hands back, but is not
 required to do so.

4.9. Stub Resolvers

 A security-aware stub resolver MUST support the DNSSEC RR types, at
 least to the extent of not mishandling responses just because they
 contain DNSSEC RRs.

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

4.9.1. Handling of the DO Bit

 A non-validating security-aware stub resolver MAY include the DNSSEC
 RRs returned by a security-aware recursive name server as part of the
 data that the stub resolver hands back to the application that
 invoked it, but is not required to do so.  A non-validating stub
 resolver that seeks to do this will need to set the DO bit in order
 to receive DNSSEC RRs from the recursive name server.
 A validating security-aware stub resolver MUST set the DO bit,
 because otherwise it will not receive the DNSSEC RRs it needs to
 perform signature validation.

4.9.2. Handling of the CD Bit

 A non-validating security-aware stub resolver SHOULD NOT set the CD
 bit when sending queries unless it is requested by the application
 layer, as by definition, a non-validating stub resolver depends on
 the security-aware recursive name server to perform validation on its
 behalf.
 A validating security-aware stub resolver SHOULD set the CD bit,
 because otherwise the security-aware recursive name server will
 answer the query using the name server's local policy, which may
 prevent the stub resolver from receiving data that would be
 acceptable to the stub resolver's local policy.

4.9.3. Handling of the AD Bit

 A non-validating security-aware stub resolver MAY chose to examine
 the setting of the AD bit in response messages that it receives in
 order to determine whether the security-aware recursive name server
 that sent the response claims to have cryptographically verified the
 data in the Answer and Authority sections of the response message.
 Note, however, that the responses received by a security-aware stub
 resolver are heavily dependent on the local policy of the
 security-aware recursive name server.  Therefore, there may be little
 practical value in checking the status of the AD bit, except perhaps
 as a debugging aid.  In any case, a security-aware stub resolver MUST
 NOT place any reliance on signature validation allegedly performed on
 its behalf, except when the security-aware stub resolver obtained the
 data in question from a trusted security-aware recursive name server
 via a secure channel.
 A validating security-aware stub resolver SHOULD NOT examine the
 setting of the AD bit in response messages, as, by definition, the
 stub resolver performs its own signature validation regardless of the
 setting of the AD bit.

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

5. Authenticating DNS Responses

 To use DNSSEC RRs for authentication, a security-aware resolver
 requires configured knowledge of at least one authenticated DNSKEY or
 DS RR.  The process for obtaining and authenticating this initial
 trust anchor is achieved via some external mechanism.  For example, a
 resolver could use some off-line authenticated exchange to obtain a
 zone's DNSKEY RR or to obtain a DS RR that identifies and
 authenticates a zone's DNSKEY RR.  The remainder of this section
 assumes that the resolver has somehow obtained an initial set of
 trust anchors.
 An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
 RRset.  To authenticate an apex DNSKEY RRset by using an initial key,
 the resolver MUST:
 1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
     RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
     bit 7) set; and
 2.  verify that there is some RRSIG RR that covers the apex DNSKEY
     RRset, and that the combination of the RRSIG RR and the initial
     DNSKEY RR authenticates the DNSKEY RRset.  The process for using
     an RRSIG RR to authenticate an RRset is described in Section 5.3.
 Once the resolver has authenticated the apex DNSKEY RRset by using an
 initial DNSKEY RR, delegations from that zone can be authenticated by
 using DS RRs.  This allows a resolver to start from an initial key
 and use DS RRsets to proceed recursively down the DNS tree, obtaining
 other apex DNSKEY RRsets.  If the resolver were configured with a
 root DNSKEY RR, and if every delegation had a DS RR associated with
 it, then the resolver could obtain and validate any apex DNSKEY
 RRset.  The process of using DS RRs to authenticate referrals is
 described in Section 5.2.
 Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
 DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
 RRsets in the zone once the resolver has authenticated a zone's apex
 DNSKEY RRset.  Section 5.4 shows how the resolver can use
 authenticated NSEC RRsets from the zone to prove that an RRset is not
 present in the zone.
 When a resolver indicates support for DNSSEC (by setting the DO bit),
 a security-aware name server should attempt to provide the necessary
 DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
 However, a security-aware resolver may still receive a response that
 lacks the appropriate DNSSEC RRs, whether due to configuration issues
 such as an upstream security-oblivious recursive name server that

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

 accidentally interferes with DNSSEC RRs or due to a deliberate attack
 in which an adversary forges a response, strips DNSSEC RRs from a
 response, or modifies a query so that DNSSEC RRs appear not to be
 requested.  The absence of DNSSEC data in a response MUST NOT by
 itself be taken as an indication that no authentication information
 exists.
 A resolver SHOULD expect authentication information from signed
 zones.  A resolver SHOULD believe that a zone is signed if the
 resolver has been configured with public key information for the
 zone, or if the zone's parent is signed and the delegation from the
 parent contains a DS RRset.

5.1. Special Considerations for Islands of Security

 Islands of security (see [RFC4033]) are signed zones for which it is
 not possible to construct an authentication chain to the zone from
 its parent.  Validating signatures within an island of security
 requires that the validator have some other means of obtaining an
 initial authenticated zone key for the island.  If a validator cannot
 obtain such a key, it SHOULD switch to operating as if the zones in
 the island of security are unsigned.
 All the normal processes for validating responses apply to islands of
 security.  The only difference between normal validation and
 validation within an island of security is in how the validator
 obtains a trust anchor for the authentication chain.

5.2. Authenticating Referrals

 Once the apex DNSKEY RRset for a signed parent zone has been
 authenticated, DS RRsets can be used to authenticate the delegation
 to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
 zone's apex DNSKEY RRset and contains a cryptographic digest of the
 child zone's DNSKEY RR.  Use of a strong cryptographic digest
 algorithm ensures that it is computationally infeasible for an
 adversary to generate a DNSKEY RR that matches the digest.  Thus,
 authenticating the digest allows a resolver to authenticate the
 matching DNSKEY RR.  The resolver can then use this child DNSKEY RR
 to authenticate the entire child apex DNSKEY RRset.
 Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
 can be authenticated if all of the following hold:
 o  The DS RR has been authenticated using some DNSKEY RR in the
    parent's apex DNSKEY RRset (see Section 5.3).

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

 o  The Algorithm and Key Tag in the DS RR match the Algorithm field
    and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
    RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
    using the digest algorithm specified in the DS RR's Digest Type
    field, the resulting digest value matches the Digest field of the
    DS RR.
 o  The matching DNSKEY RR in the child zone has the Zone Flag bit
    set, the corresponding private key has signed the child zone's
    apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
    child zone's apex DNSKEY RRset.
 If the referral from the parent zone did not contain a DS RRset, the
 response should have included a signed NSEC RRset proving that no DS
 RRset exists for the delegated name (see Section 3.1.4).  A
 security-aware resolver MUST query the name servers for the parent
 zone for the DS RRset if the referral includes neither a DS RRset nor
 a NSEC RRset proving that the DS RRset does not exist (see Section
 4).
 If the validator authenticates an NSEC RRset that proves that no DS
 RRset is present for this zone, then there is no authentication path
 leading from the parent to the child.  If the resolver has an initial
 DNSKEY or DS RR that belongs to the child zone or to any delegation
 below the child zone, this initial DNSKEY or DS RR MAY be used to
 re-establish an authentication path.  If no such initial DNSKEY or DS
 RR exists, the validator cannot authenticate RRsets in or below the
 child zone.
 If the validator does not support any of the algorithms listed in an
 authenticated DS RRset, then the resolver has no supported
 authentication path leading from the parent to the child.  The
 resolver should treat this case as it would the case of an
 authenticated NSEC RRset proving that no DS RRset exists, as
 described above.
 Note that, for a signed delegation, there are two NSEC RRs associated
 with the delegated name.  One NSEC RR resides in the parent zone and
 can be used to prove whether a DS RRset exists for the delegated
 name.  The second NSEC RR resides in the child zone and identifies
 which RRsets are present at the apex of the child zone.  The parent
 NSEC RR and child NSEC RR can always be distinguished because the SOA
 bit will be set in the child NSEC RR and clear in the parent NSEC RR.
 A security-aware resolver MUST use the parent NSEC RR when attempting
 to prove that a DS RRset does not exist.

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

 If the resolver does not support any of the algorithms listed in an
 authenticated DS RRset, then the resolver will not be able to verify
 the authentication path to the child zone.  In this case, the
 resolver SHOULD treat the child zone as if it were unsigned.

5.3. Authenticating an RRset with an RRSIG RR

 A validator can use an RRSIG RR and its corresponding DNSKEY RR to
 attempt to authenticate RRsets.  The validator first checks the RRSIG
 RR to verify that it covers the RRset, has a valid time interval, and
 identifies a valid DNSKEY RR.  The validator then constructs the
 canonical form of the signed data by appending the RRSIG RDATA
 (excluding the Signature Field) with the canonical form of the
 covered RRset.  Finally, the validator uses the public key and
 signature to authenticate the signed data.  Sections 5.3.1, 5.3.2,
 and 5.3.3 describe each step in detail.

5.3.1. Checking the RRSIG RR Validity

 A security-aware resolver can use an RRSIG RR to authenticate an
 RRset if all of the following conditions hold:
 o  The RRSIG RR and the RRset MUST have the same owner name and the
    same class.
 o  The RRSIG RR's Signer's Name field MUST be the name of the zone
    that contains the RRset.
 o  The RRSIG RR's Type Covered field MUST equal the RRset's type.
 o  The number of labels in the RRset owner name MUST be greater than
    or equal to the value in the RRSIG RR's Labels field.
 o  The validator's notion of the current time MUST be less than or
    equal to the time listed in the RRSIG RR's Expiration field.
 o  The validator's notion of the current time MUST be greater than or
    equal to the time listed in the RRSIG RR's Inception field.
 o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
    match the owner name, algorithm, and key tag for some DNSKEY RR in
    the zone's apex DNSKEY RRset.
 o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
    RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
    set.

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

 It is possible for more than one DNSKEY RR to match the conditions
 above.  In this case, the validator cannot predetermine which DNSKEY
 RR to use to authenticate the signature, and it MUST try each
 matching DNSKEY RR until either the signature is validated or the
 validator has run out of matching public keys to try.
 Note that this authentication process is only meaningful if the
 validator authenticates the DNSKEY RR before using it to validate
 signatures.  The matching DNSKEY RR is considered to be authentic if:
 o  the apex DNSKEY RRset containing the DNSKEY RR is considered
    authentic; or
 o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
    and the DNSKEY RR either matches an authenticated DS RR from the
    parent zone or matches a trust anchor.

5.3.2. Reconstructing the Signed Data

 Once the RRSIG RR has met the validity requirements described in
 Section 5.3.1, the validator has to reconstruct the original signed
 data.  The original signed data includes RRSIG RDATA (excluding the
 Signature field) and the canonical form of the RRset.  Aside from
 being ordered, the canonical form of the RRset might also differ from
 the received RRset due to DNS name compression, decremented TTLs, or
 wildcard expansion.  The validator should use the following to
 reconstruct the original signed data:
       signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
          "|" denotes concatenation
          RRSIG_RDATA is the wire format of the RRSIG RDATA fields
             with the Signature field excluded and the Signer's Name
             in canonical form.
          RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
             name is calculated according to the function below
             class is the RRset's class
             type is the RRset type and all RRs in the class
             OrigTTL is the value from the RRSIG Original TTL field
             All names in the RDATA field are in canonical form

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

             The set of all RR(i) is sorted into canonical order.
          To calculate the name:
             let rrsig_labels = the value of the RRSIG Labels field
             let fqdn = RRset's fully qualified domain name in
                             canonical form
             let fqdn_labels = Label count of the fqdn above.
             if rrsig_labels = fqdn_labels,
                 name = fqdn
             if rrsig_labels < fqdn_labels,
                name = "*." | the rightmost rrsig_label labels of the
                              fqdn
             if rrsig_labels > fqdn_labels
                the RRSIG RR did not pass the necessary validation
                checks and MUST NOT be used to authenticate this
                RRset.
 The canonical forms for names and RRsets are defined in [RFC4034].
 NSEC RRsets at a delegation boundary require special processing.
 There are two distinct NSEC RRsets associated with a signed delegated
 name.  One NSEC RRset resides in the parent zone, and specifies which
 RRsets are present at the parent zone.  The second NSEC RRset resides
 at the child zone and identifies which RRsets are present at the apex
 in the child zone.  The parent NSEC RRset and child NSEC RRset can
 always be distinguished as only a child NSEC RR will indicate that an
 SOA RRset exists at the name.  When reconstructing the original NSEC
 RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
 be combined with NSEC RRs from the child zone.  When reconstructing
 the original NSEC RRset for the apex of the child zone, the NSEC RRs
 MUST NOT be combined with NSEC RRs from the parent zone.
 Note that each of the two NSEC RRsets at a delegation point has a
 corresponding RRSIG RR with an owner name matching the delegated
 name, and each of these RRSIG RRs is authoritative data associated
 with the same zone that contains the corresponding NSEC RRset.  If
 necessary, a resolver can tell these RRSIG RRs apart by checking the
 Signer's Name field.

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

5.3.3. Checking the Signature

 Once the resolver has validated the RRSIG RR as described in Section
 5.3.1 and reconstructed the original signed data as described in
 Section 5.3.2, the validator can attempt to use the cryptographic
 signature to authenticate the signed data, and thus (finally!)
 authenticate the RRset.
 The Algorithm field in the RRSIG RR identifies the cryptographic
 algorithm used to generate the signature.  The signature itself is
 contained in the Signature field of the RRSIG RDATA, and the public
 key used to verify the signature is contained in the Public Key field
 of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]
 provides a list of algorithm types and provides pointers to the
 documents that define each algorithm's use.
 Note that it is possible for more than one DNSKEY RR to match the
 conditions in Section 5.3.1.  In this case, the validator can only
 determine which DNSKEY RR is correct by trying each matching public
 key until the validator either succeeds in validating the signature
 or runs out of keys to try.
 If the Labels field of the RRSIG RR is not equal to the number of
 labels in the RRset's fully qualified owner name, then the RRset is
 either invalid or the result of wildcard expansion.  The resolver
 MUST verify that wildcard expansion was applied properly before
 considering the RRset to be authentic.  Section 5.3.4 describes how
 to determine whether a wildcard was applied properly.
 If other RRSIG RRs also cover this RRset, the local resolver security
 policy determines whether the resolver also has to test these RRSIG
 RRs and how to resolve conflicts if these RRSIG RRs lead to differing
 results.
 If the resolver accepts the RRset as authentic, the validator MUST
 set the TTL of the RRSIG RR and each RR in the authenticated RRset to
 a value no greater than the minimum of:
 o  the RRset's TTL as received in the response;
 o  the RRSIG RR's TTL as received in the response;
 o  the value in the RRSIG RR's Original TTL field; and
 o  the difference of the RRSIG RR's Signature Expiration time and the
    current time.

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

5.3.4. Authenticating a Wildcard Expanded RRset Positive Response

 If the number of labels in an RRset's owner name is greater than the
 Labels field of the covering RRSIG RR, then the RRset and its
 covering RRSIG RR were created as a result of wildcard expansion.
 Once the validator has verified the signature, as described in
 Section 5.3, it must take additional steps to verify the non-
 existence of an exact match or closer wildcard match for the query.
 Section 5.4 discusses these steps.
 Note that the response received by the resolver should include all
 NSEC RRs needed to authenticate the response (see Section 3.1.3).

5.4. Authenticated Denial of Existence

 A resolver can use authenticated NSEC RRs to prove that an RRset is
 not present in a signed zone.  Security-aware name servers should
 automatically include any necessary NSEC RRs for signed zones in
 their responses to security-aware resolvers.
 Denial of existence is determined by the following rules:
 o  If the requested RR name matches the owner name of an
    authenticated NSEC RR, then the NSEC RR's type bit map field lists
    all RR types present at that owner name, and a resolver can prove
    that the requested RR type does not exist by checking for the RR
    type in the bit map.  If the number of labels in an authenticated
    NSEC RR's owner name equals the Labels field of the covering RRSIG
    RR, then the existence of the NSEC RR proves that wildcard
    expansion could not have been used to match the request.
 o  If the requested RR name would appear after an authenticated NSEC
    RR's owner name and before the name listed in that NSEC RR's Next
    Domain Name field according to the canonical DNS name order
    defined in [RFC4034], then no RRsets with the requested name exist
    in the zone.  However, it is possible that a wildcard could be
    used to match the requested RR owner name and type, so proving
    that the requested RRset does not exist also requires proving that
    no possible wildcard RRset exists that could have been used to
    generate a positive response.
 In addition, security-aware resolvers MUST authenticate the NSEC
 RRsets that comprise the non-existence proof as described in Section
 5.3.
 To prove the non-existence of an RRset, the resolver must be able to
 verify both that the queried RRset does not exist and that no
 relevant wildcard RRset exists.  Proving this may require more than

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

 one NSEC RRset from the zone.  If the complete set of necessary NSEC
 RRsets is not present in a response (perhaps due to message
 truncation), then a security-aware resolver MUST resend the query in
 order to attempt to obtain the full collection of NSEC RRs necessary
 to verify the non-existence of the requested RRset.  As with all DNS
 operations, however, the resolver MUST bound the work it puts into
 answering any particular query.
 Since a validated NSEC RR proves the existence of both itself and its
 corresponding RRSIG RR, a validator MUST ignore the settings of the
 NSEC and RRSIG bits in an NSEC RR.

5.5. Resolver Behavior When Signatures Do Not Validate

 If for whatever reason none of the RRSIGs can be validated, the
 response SHOULD be considered BAD.  If the validation was being done
 to service a recursive query, the name server MUST return RCODE 2 to
 the originating client.  However, it MUST return the full response if
 and only if the original query had the CD bit set.  Also see Section
 4.7 on caching responses that do not validate.

5.6. Authentication Example

 Appendix C shows an example of the authentication process.

6. IANA Considerations

 [RFC4034] contains a review of the IANA considerations introduced by
 DNSSEC.  The following are additional IANA considerations discussed
 in this document:
 [RFC2535] reserved the CD and AD bits in the message header.  The
 meaning of the AD bit was redefined in [RFC3655], and the meaning of
 both the CD and AD bit are restated in this document.  No new bits in
 the DNS message header are defined in this document.
 [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
 and defined its use.  The use is restated but not altered in this
 document.

7. Security Considerations

 This document describes how the DNS security extensions use public
 key cryptography to sign and authenticate DNS resource record sets.
 Please see [RFC4033] for terminology and general security
 considerations related to DNSSEC; see [RFC4034] for considerations
 specific to the DNSSEC resource record types.

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

 An active attacker who can set the CD bit in a DNS query message or
 the AD bit in a DNS response message can use these bits to defeat the
 protection that DNSSEC attempts to provide to security-oblivious
 recursive-mode resolvers.  For this reason, use of these control bits
 by a security-aware recursive-mode resolver requires a secure
 channel.  See Sections 3.2.2 and 4.9 for further discussion.
 The protocol described in this document attempts to extend the
 benefits of DNSSEC to security-oblivious stub resolvers.  However, as
 recovery from validation failures is likely to be specific to
 particular applications, the facilities that DNSSEC provides for stub
 resolvers may prove inadequate.  Operators of security-aware
 recursive name servers will have to pay close attention to the
 behavior of the applications that use their services when choosing a
 local validation policy; failure to do so could easily result in the
 recursive name server accidentally denying service to the clients it
 is intended to support.

8. Acknowledgements

 This document was created from the input and ideas of the members of
 the DNS Extensions Working Group and working group mailing list.  The
 editors would like to express their thanks for the comments and
 suggestions received during the revision of these security extension
 specifications.  Although explicitly listing everyone who has
 contributed during the decade in which DNSSEC has been under
 development would be impossible, [RFC4033] includes a list of some of
 the participants who were kind enough to comment on these documents.

9. References

9.1. Normative References

 [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, November 1987.
 [RFC1035]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, November 1987.
 [RFC1122]  Braden, R., "Requirements for Internet Hosts -
            Communication Layers", STD 3, RFC 1122, October 1989.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
            Specification", RFC 2181, July 1997.

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

 [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.
 [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
            2671, August 1999.
 [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
            2672, August 1999.
 [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
            3225, December 2001.
 [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
            message size requirements", RFC 3226, December 2001.
 [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "DNS Security Introduction and Requirements", RFC
            4033, March 2005.
 [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "Resource Records for DNS Security Extensions", RFC
            4034, March 2005.

9.2. Informative References

 [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
            NCACHE)", RFC 2308, March 1998.
 [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
            Extensions", RFC 2535, March 1999.
 [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
            Update", RFC 3007, November 2000.
 [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
            Authenticated Data (AD) bit", RFC 3655, November 2003.

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

Appendix A. Signed Zone Example

 The following example shows a (small) complete signed zone.
 example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                            1081539377
                            3600
                            300
                            3600000
                            3600
                            )
                3600 RRSIG  SOA 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                            7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                            vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                            DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                            jV7j86HyQgM5e7+miRAz8V01b0I= )
                3600 NS     ns1.example.
                3600 NS     ns2.example.
                3600 RRSIG  NS 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
                            EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
                            4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
                            RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
                            0HjMeRaZB/FRPGfJPajngcq6Kwg= )
                3600 MX     1 xx.example.
                3600 RRSIG  MX 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
                            2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
                            VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
                            6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
                            W6OISukd1EQt7a0kygkg+PEDxdI= )
                3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
                3600 RRSIG  NSEC 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
                            FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
                            Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
                            SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
                            jfFJ5arXf4nPxp/kEowGgBRzY/U= )
                3600 DNSKEY 256 3 5 (
                            AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
                            rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
                            k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
                            vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI

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

                            ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
                            )
                3600 DNSKEY 257 3 5 (
                            AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
                            LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
                            syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
                            RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
                            Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
                            )
                3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
                            20040409183619 9465 example.
                            ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
                            xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
                            XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
                            hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
                            NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
                3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
                            DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
                            bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
                            eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
                            7z5OXogYVaFzHKillDt3HRxHIZM= )
 a.example.     3600 IN NS  ns1.a.example.
                3600 IN NS  ns2.a.example.
                3600 DS     57855 5 1 (
                            B6DCD485719ADCA18E5F3D48A2331627FDD3
                            636B )
                3600 RRSIG  DS 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
                            oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
                            kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
                            EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
                            Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
                3600 NSEC   ai.example. NS DS RRSIG NSEC
                3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
                            U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
                            039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
                            BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
                            sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
 ns1.a.example. 3600 IN A   192.0.2.5
 ns2.a.example. 3600 IN A   192.0.2.6
 ai.example.    3600 IN A   192.0.2.9
                3600 RRSIG  A 5 2 3600 20040509183619 (
                            20040409183619 38519 example.

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

                            pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
                            ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
                            hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
                            ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
                            6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
                3600 HINFO  "KLH-10" "ITS"
                3600 RRSIG  HINFO 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
                            e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
                            ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
                            AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
                            FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
                3600 AAAA   2001:db8::f00:baa9
                3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
                            kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
                            1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
                            cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
                            sZM6QjBBLmukH30+w1z3h8PUP2o= )
                3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
                3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
                            CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
                            P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
                            3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
                            AhS+JOVfDI/79QtyTI0SaDWcg8U= )
 b.example.     3600 IN NS  ns1.b.example.
                3600 IN NS  ns2.b.example.
                3600 NSEC   ns1.example. NS RRSIG NSEC
                3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
                            9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
                            xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
                            0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
                            vhRXgWT7OuFXldoCG6TfVFMs9xE= )
 ns1.b.example. 3600 IN A   192.0.2.7
 ns2.b.example. 3600 IN A   192.0.2.8
 ns1.example.   3600 IN A   192.0.2.1
                3600 RRSIG  A 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
                            5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
                            im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
                            +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK

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

                            v/iVXSYC0b7mPSU+EOlknFpVECs= )
                3600 NSEC   ns2.example. A RRSIG NSEC
                3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
                            1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
                            jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
                            ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
                            IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
 ns2.example.   3600 IN A   192.0.2.2
                3600 RRSIG  A 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
                            Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
                            yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
                            6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
                            rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
                3600 NSEC   *.w.example. A RRSIG NSEC
                3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
                            VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
                            3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
                            l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
                            Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
 *.w.example.   3600 IN MX  1 ai.example.
                3600 RRSIG  MX 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                            f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                            tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                            TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                            4kX18MMR34i8lC36SR5xBni8vHI= )
                3600 NSEC   x.w.example. MX RRSIG NSEC
                3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
                            HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
                            5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
                            91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
                            s1InQ2UoIv6tJEaaKkP701j8OLA= )
 x.w.example.   3600 IN MX  1 xx.example.
                3600 RRSIG  MX 5 3 3600 20040509183619 (
                            20040409183619 38519 example.
                            Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
                            XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
                            H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
                            kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1

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

                            jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
                3600 NSEC   x.y.w.example. MX RRSIG NSEC
                3600 RRSIG  NSEC 5 3 3600 20040509183619 (
                            20040409183619 38519 example.
                            aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
                            vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
                            mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
                            NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
                            IjgiM8PXkBQtxPq37wDKALkyn7Q= )
 x.y.w.example. 3600 IN MX  1 xx.example.
                3600 RRSIG  MX 5 4 3600 20040509183619 (
                            20040409183619 38519 example.
                            k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
                            t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
                            q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
                            GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
                            +gLcMZBnHJ326nb/TOOmrqNmQQE= )
                3600 NSEC   xx.example. MX RRSIG NSEC
                3600 RRSIG  NSEC 5 4 3600 20040509183619 (
                            20040409183619 38519 example.
                            OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
                            ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
                            xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
                            a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
                            QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
 xx.example.    3600 IN A   192.0.2.10
                3600 RRSIG  A 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
                            7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
                            0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
                            VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
                            kbIDV6GPPSZVusnZU6OMgdgzHV4= )
                3600 HINFO  "KLH-10" "TOPS-20"
                3600 RRSIG  HINFO 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
                            t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
                            BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
                            3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
                            RgNvuwbioFSEuv2pNlkq0goYxNY= )
                3600 AAAA   2001:db8::f00:baaa
                3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
                            aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
                            ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
                            U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/

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

                            xS9cL2QgW7FChw16mzlkH6/vsfs= )
                3600 NSEC   example. A HINFO AAAA RRSIG NSEC
                3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
                            9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
                            mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
                            asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
                            GghLahumFIpg4MO3LS/prgzVVWo= )
 The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
 Flags indicate that each of these DNSKEY RRs is a zone key.  One of
 these DNSKEY RRs also has the SEP flag set and has been used to sign
 the apex DNSKEY RRset; this is the key that should be hashed to
 generate a DS record to be inserted into the parent zone.  The other
 DNSKEY is used to sign all the other RRsets in the zone.
 The zone includes a wildcard entry, "*.w.example".  Note that the
 name "*.w.example" is used in constructing NSEC chains, and that the
 RRSIG covering the "*.w.example" MX RRset has a label count of 2.
 The zone also includes two delegations.  The delegation to
 "b.example" includes an NS RRset, glue address records, and an NSEC
 RR; note that only the NSEC RRset is signed.  The delegation to
 "a.example" provides a DS RR; note that only the NSEC and DS RRsets
 are signed.

Appendix B. Example Responses

 The examples in this section show response messages using the signed
 zone example in Appendix A.

B.1. Answer

 A successful query to an authoritative server.
 ;; Header: QR AA DO RCODE=0
 ;;
 ;; Question
 x.w.example.        IN MX
 ;; Answer
 x.w.example.   3600 IN MX  1 xx.example.
 x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
                            20040409183619 38519 example.
                            Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
                            XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
                            H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I

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

                            kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
                            jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
 ;; Authority
 example.       3600 NS     ns1.example.
 example.       3600 NS     ns2.example.
 example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
                            EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
                            4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
                            RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
                            0HjMeRaZB/FRPGfJPajngcq6Kwg= )
 ;; Additional
 xx.example.    3600 IN A   192.0.2.10
 xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
                            7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
                            0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
                            VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
                            kbIDV6GPPSZVusnZU6OMgdgzHV4= )
 xx.example.    3600 AAAA   2001:db8::f00:baaa
 xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
                            aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
                            ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
                            U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
                            xS9cL2QgW7FChw16mzlkH6/vsfs= )
 ns1.example.   3600 IN A   192.0.2.1
 ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
                            5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
                            im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
                            +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
                            v/iVXSYC0b7mPSU+EOlknFpVECs= )
 ns2.example.   3600 IN A   192.0.2.2
 ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
                            Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
                            yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
                            6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
                            rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )

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

B.2. Name Error

 An authoritative name error.  The NSEC RRs prove that the name does
 not exist and that no covering wildcard exists.
 ;; Header: QR AA DO RCODE=3
 ;;
 ;; Question
 ml.example.         IN A
 ;; Answer
 ;; (empty)
 ;; Authority
 example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                            1081539377
                            3600
                            300
                            3600000
                            3600
                            )
 example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                            7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                            vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                            DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                            jV7j86HyQgM5e7+miRAz8V01b0I= )
 b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
 b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
                            9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
                            xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
                            0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
                            vhRXgWT7OuFXldoCG6TfVFMs9xE= )
 example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
 example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
                            FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
                            Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
                            SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
                            jfFJ5arXf4nPxp/kEowGgBRzY/U= )
 ;; Additional
 ;; (empty)

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

B.3. No Data Error

 A "no data" response.  The NSEC RR proves that the name exists and
 that the requested RR type does not.
 ;; Header: QR AA DO RCODE=0
 ;;
 ;; Question
 ns1.example.        IN MX
 ;; Answer
 ;; (empty)
 ;; Authority
 example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                            1081539377
                            3600
                            300
                            3600000
                            3600
                            )
 example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                            7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                            vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                            DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                            jV7j86HyQgM5e7+miRAz8V01b0I= )
 ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
 ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
                            1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
                            jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
                            ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
                            IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
 ;; Additional
 ;; (empty)

B.4. Referral to Signed Zone

 Referral to a signed zone.  The DS RR contains the data which the
 resolver will need to validate the corresponding DNSKEY RR in the
 child zone's apex.
 ;; Header: QR DO RCODE=0
 ;;

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

 ;; Question
 mc.a.example.       IN MX
 ;; Answer
 ;; (empty)
 ;; Authority
 a.example.     3600 IN NS  ns1.a.example.
 a.example.     3600 IN NS  ns2.a.example.
 a.example.     3600 DS     57855 5 1 (
                            B6DCD485719ADCA18E5F3D48A2331627FDD3
                            636B )
 a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
                            oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
                            kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
                            EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
                            Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
 ;; Additional
 ns1.a.example. 3600 IN A   192.0.2.5
 ns2.a.example. 3600 IN A   192.0.2.6

B.5. Referral to Unsigned Zone

 Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
 this delegation exists in the parent zone.
 ;; Header: QR DO RCODE=0
 ;;
 ;; Question
 mc.b.example.       IN MX
 ;; Answer
 ;; (empty)
 ;; Authority
 b.example.     3600 IN NS  ns1.b.example.
 b.example.     3600 IN NS  ns2.b.example.
 b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
 b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
                            9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
                            xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
                            0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
                            vhRXgWT7OuFXldoCG6TfVFMs9xE= )

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

 ;; Additional
 ns1.b.example. 3600 IN A   192.0.2.7
 ns2.b.example. 3600 IN A   192.0.2.8

B.6. Wildcard Expansion

 A successful query that was answered via wildcard expansion.  The
 label count in the answer's RRSIG RR indicates that a wildcard RRset
 was expanded to produce this response, and the NSEC RR proves that no
 closer match exists in the zone.
 ;; Header: QR AA DO RCODE=0
 ;;
 ;; Question
 a.z.w.example.      IN MX
 ;; Answer
 a.z.w.example. 3600 IN MX  1 ai.example.
 a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                            f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                            tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                            TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                            4kX18MMR34i8lC36SR5xBni8vHI= )
 ;; Authority
 example.       3600 NS     ns1.example.
 example.       3600 NS     ns2.example.
 example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
                            EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
                            4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
                            RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
                            0HjMeRaZB/FRPGfJPajngcq6Kwg= )
 x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
 x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
                            20040409183619 38519 example.
                            OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
                            ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
                            xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
                            a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
                            QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
 ;; Additional
 ai.example.    3600 IN A   192.0.2.9
 ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (

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

                            20040409183619 38519 example.
                            pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
                            ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
                            hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
                            ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
                            6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
 ai.example.    3600 AAAA   2001:db8::f00:baa9
 ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
                            kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
                            1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
                            cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
                            sZM6QjBBLmukH30+w1z3h8PUP2o= )

B.7. Wildcard No Data Error

 A "no data" response for a name covered by a wildcard.  The NSEC RRs
 prove that the matching wildcard name does not have any RRs of the
 requested type and that no closer match exists in the zone.
 ;; Header: QR AA DO RCODE=0
 ;;
 ;; Question
 a.z.w.example.      IN AAAA
 ;; Answer
 ;; (empty)
 ;; Authority
 example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                            1081539377
                            3600
                            300
                            3600000
                            3600
                            )
 example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                            7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                            vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                            DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                            jV7j86HyQgM5e7+miRAz8V01b0I= )
 x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
 x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
                            20040409183619 38519 example.
                            OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp

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

                            ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
                            xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
                            a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
                            QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
 *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
 *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                            20040409183619 38519 example.
                            r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
                            HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
                            5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
                            91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
                            s1InQ2UoIv6tJEaaKkP701j8OLA= )
 ;; Additional
 ;; (empty)

B.8. DS Child Zone No Data Error

 A "no data" response for a QTYPE=DS query that was mistakenly sent to
 a name server for the child zone.
 ;; Header: QR AA DO RCODE=0
 ;;
 ;; Question
 example.            IN DS
 ;; Answer
 ;; (empty)
 ;; Authority
 example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                            1081539377
                            3600
                            300
                            3600000
                            3600
                            )
 example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                            7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                            vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                            DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                            jV7j86HyQgM5e7+miRAz8V01b0I= )
 example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
 example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
                            20040409183619 38519 example.
                            O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm

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

                            FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
                            Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
                            SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
                            jfFJ5arXf4nPxp/kEowGgBRzY/U= )
 ;; Additional
 ;; (empty)

Appendix C. Authentication Examples

 The examples in this section show how the response messages in
 Appendix B are authenticated.

C.1. Authenticating an Answer

 The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
 The corresponding RRSIG indicates that the MX RRset was signed by an
 "example" DNSKEY with algorithm 5 and key tag 38519.  The resolver
 needs the corresponding DNSKEY RR in order to authenticate this
 answer.  The discussion below describes how a resolver might obtain
 this DNSKEY RR.
 The RRSIG indicates the original TTL of the MX RRset was 3600, and,
 for the purpose of authentication, the current TTL is replaced by
 3600.  The RRSIG labels field value of 3 indicates that the answer
 was not the result of wildcard expansion.  The "x.w.example.com" MX
 RRset is placed in canonical form, and, assuming the current time
 falls between the signature inception and expiration dates, the
 signature is authenticated.

C.1.1. Authenticating the Example DNSKEY RR

 This example shows the logical authentication process that starts
 from the a configured root DNSKEY (or DS RR) and moves down the tree
 to authenticate the desired "example" DNSKEY RR.  Note that the
 logical order is presented for clarity.  An implementation may choose
 to construct the authentication as referrals are received or to
 construct the authentication chain only after all RRsets have been
 obtained, or in any other combination it sees fit.  The example here
 demonstrates only the logical process and does not dictate any
 implementation rules.
 We assume the resolver starts with a configured DNSKEY RR for the
 root zone (or a configured DS RR for the root zone).  The resolver
 checks whether this configured DNSKEY RR is present in the root
 DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
 DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
 RRset, and whether the signature lifetime is valid.  If all these

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

 conditions are met, all keys in the DNSKEY RRset are considered
 authenticated.  The resolver then uses one (or more) of the root
 DNSKEY RRs to authenticate the "example" DS RRset.  Note that the
 resolver may have to query the root zone to obtain the root DNSKEY
 RRset or "example" DS RRset.
 Once the DS RRset has been authenticated using the root DNSKEY, the
 resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
 RR that matches one of the authenticated "example" DS RRs.  If such a
 matching "example" DNSKEY is found, the resolver checks whether this
 DNSKEY RR has signed the "example" DNSKEY RRset and the signature
 lifetime is valid.  If these conditions are met, all keys in the
 "example" DNSKEY RRset are considered authenticated.
 Finally, the resolver checks that some DNSKEY RR in the "example"
 DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
 DNSKEY is used to authenticate the RRSIG included in the response.
 If multiple "example" DNSKEY RRs match this algorithm and key tag,
 then each DNSKEY RR is tried, and the answer is authenticated if any
 of the matching DNSKEY RRs validate the signature as described above.

C.2. Name Error

 The query in Appendix B.2 returned NSEC RRs that prove that the
 requested data does not exist and no wildcard applies.  The negative
 reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
 authenticated in a manner identical to that of the MX RRset discussed
 above.

C.3. No Data Error

 The query in Appendix B.3 returned an NSEC RR that proves that the
 requested name exists, but the requested RR type does not exist.  The
 negative reply is authenticated by verifying the NSEC RR.  The NSEC
 RR is authenticated in a manner identical to that of the MX RRset
 discussed above.

C.4. Referral to Signed Zone

 The query in Appendix B.4 returned a referral to the signed
 "a.example." zone.  The DS RR is authenticated in a manner identical
 to that of the MX RRset discussed above.  This DS RR is used to
 authenticate the "a.example" DNSKEY RRset.
 Once the "a.example" DS RRset has been authenticated using the
 "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
 for some "a.example" DNSKEY RR that matches the DS RR.  If such a
 matching "a.example" DNSKEY is found, the resolver checks whether

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

 this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
 the signature lifetime is valid.  If all these conditions are met,
 all keys in the "a.example" DNSKEY RRset are considered
 authenticated.

C.5. Referral to Unsigned Zone

 The query in Appendix B.5 returned a referral to an unsigned
 "b.example." zone.  The NSEC proves that no authentication leads from
 "example" to "b.example", and the NSEC RR is authenticated in a
 manner identical to that of the MX RRset discussed above.

C.6. Wildcard Expansion

 The query in Appendix B.6 returned an answer that was produced as a
 result of wildcard expansion.  The answer section contains a wildcard
 RRset expanded as it would be in a traditional DNS response, and the
 corresponding RRSIG indicates that the expanded wildcard MX RRset was
 signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
 The RRSIG indicates that the original TTL of the MX RRset was 3600,
 and, for the purpose of authentication, the current TTL is replaced
 by 3600.  The RRSIG labels field value of 2 indicates that the answer
 is the result of wildcard expansion, as the "a.z.w.example" name
 contains 4 labels.  The name "a.z.w.w.example" is replaced by
 "*.w.example", the MX RRset is placed in canonical form, and,
 assuming that the current time falls between the signature inception
 and expiration dates, the signature is authenticated.
 The NSEC proves that no closer match (exact or closer wildcard) could
 have been used to answer this query, and the NSEC RR must also be
 authenticated before the answer is considered valid.

C.7. Wildcard No Data Error

 The query in Appendix B.7 returned NSEC RRs that prove that the
 requested data does not exist and no wildcard applies.  The negative
 reply is authenticated by verifying both NSEC RRs.

C.8. DS Child Zone No Data Error

 The query in Appendix B.8 returned NSEC RRs that shows the requested
 was answered by a child server ("example" server).  The NSEC RR
 indicates the presence of an SOA RR, showing that the answer is from
 the child .  Queries for the "example" DS RRset should be sent to the
 parent servers ("root" servers).

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

Authors' Addresses

 Roy Arends
 Telematica Instituut
 Brouwerijstraat 1
 7523 XC  Enschede
 NL
 EMail: roy.arends@telin.nl
 Rob Austein
 Internet Systems Consortium
 950 Charter Street
 Redwood City, CA  94063
 USA
 EMail: sra@isc.org
 Matt Larson
 VeriSign, Inc.
 21345 Ridgetop Circle
 Dulles, VA  20166-6503
 USA
 EMail: mlarson@verisign.com
 Dan Massey
 Colorado State University
 Department of Computer Science
 Fort Collins, CO 80523-1873
 EMail: massey@cs.colostate.edu
 Scott Rose
 National Institute for Standards and Technology
 100 Bureau Drive
 Gaithersburg, MD  20899-8920
 USA
 EMail: scott.rose@nist.gov

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

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Arends, et al. Standards Track [Page 53]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4035.txt · Last modified: 2005/03/25 20:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki