DNS Extensions                                                 R. Arends
Internet-Draft                                      Telematica Instituut
Expires: March 30, April 26, 2004                                        M. Larson
                                                                VeriSign
                                                              R. Austein
                                                                     ISC
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                      September 30,
                                                        October 27, 2003

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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on March 30, April 26, 2004.

Copyright Notice

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

Abstract

   This document is part of a family of documents which describes describe the DNS
   Security Extensions (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and protocol modifications which
   add data origin authentication and data integrity to the DNS.  This
   document describes the DNSSEC protocol modifications.  This document
   defines the concept of a signed zone, along with the requirements for
   serving and resolving using DNSSEC.  These techniques allow a
   security-aware resolver to authenticate both DNS resource records and
   authoritative DNS error indications.

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

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Background and Related Documents . . . . . . . . . . . . . .  4
   1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3   Editors' Notes . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.1 Open Technical Issues  . . . . . . . . . . . . . . . . . . .  4
   1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . .  4
   1.3.3 Typos and Minor Corrections  . . . . . . . . . . . . . . . .  5
   2.    Zone Signing . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1   Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . .  6
   2.2   Including RRSIG RRs in a Zone  . . . . . . . . . . . . . . .  6
   2.3   Including NSEC RRs in a Zone . . . . . . . . . . . . . . . .  7  8
   2.4   Including DS RRs in a Zone . . . . . . . . . . . . . . . . .  8
   2.5   Changes to the CNAME Resource Record.  . . . . . . . . . . .  8
   2.6   Example of a Secure Zone . . . . . . . . . . . . . . . . . .  8
   3.    Serving  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1   Authoritative Name Servers . . . . . . . . . . . . . . . . .  9
   3.1.1 Including RRSIG RRs in a Response  . . . . . . . . . . . . .  9
   3.2 10
   3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10
   3.3
   3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 10
   3.3.1 Case 1: QNAME is Associated with RRsets, but RR 11
   3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13
   3.1.5 Responding to Queries for Type Not
         Present AXFR or IXFR  . . . . . . . . 14
   3.1.6 The AD and CD Bits in an Authoritative Response  . . . . . . 15
   3.2   Recursive Name Servers . . . . . . . . . . . . 11
   3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches . . . 11
   3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches . . . . 16
   3.2.1 The DO bit . 11
   3.4   Including DS RRs In a Response . . . . . . . . . . . . . . . 12
   3.5   Responding to Queries for DS RRs . . . . . . . . . 16
   3.2.2 The CD bit . . . . . 12
   3.6   Responding to Queries for Type AXFR or IXFR . . . . . . . . 13
   3.7   Setting the . . . . . . . . . . . . 17
   3.2.3 The AD and CD Bits in a Response bit . . . . . . . . . . 14
   3.8 . . . . . . . . . . . . . . . 18
   3.3   Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 15 18
   4.    Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   4.1   Recursive Name Servers   Rate Limiting  . . . . . . . . . . . . . . . . . . . . . . . 21
   4.2   Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 22 21
   5.    Authenticating DNS Responses . . . . . . . . . . . . . . . . 24 23
   5.1   Special Considerations for Islands of Security . . . . . . . 25 24
   5.2   Authenticating Referrals . . . . . . . . . . . . . . . . . . 25 24
   5.3   Authenticating an RRset Using an RRSIG RR  . . . . . . . . . 26 25
   5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 27 26
   5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28 27
   5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 29 28
   5.3.4 Authenticating A Wildcard Expanded RRset Positive
         Response . . . . . . . . . . . . . . . . . . . . . . . . . . 30 29
   5.4   Authenticated Denial of Existence  . . . . . . . . . . . . . 30
   5.5   Examples 29
   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 31
   7.    Security Considerations  . . . . . . 31
   5.5.1 Example of Re-Constructing the Original Owner Name . . . . . 31
   5.5.2 Examples of Authenticating a Response . . . . . . . 32
   8.    Acknowledgements . . . . 32
   6.    IANA Considerations . . . . . . . . . . . . . . . . . . 33
         Normative References . . 33
   7.    Security Considerations . . . . . . . . . . . . . . . . . . 34
   8.    Acknowledgements .
         Informative References . . . . . . . . . . . . . . . . . . . 35
         Authors' Addresses . . 35
         Normative References . . . . . . . . . . . . . . . . . . . 35
   A.    Signed Zone Example  . 36
         Informative References . . . . . . . . . . . . . . . . . . . 37
         Authors' Addresses
   B.    Example Responses  . . . . . . . . . . . . . . . . . . . . . 37
   A.    Algorithm For Handling Wildcard Expansion 43
   B.1   Answer . . . . . . . . . 39
   B.    Signed Zone Example . . . . . . . . . . . . . . . . . . 43
   B.2   Name Error . . 40
         Intellectual Property and Copyright Statements . . . . . . . 46

1. Introduction

   The DNS . . . . . . . . . . . . . . . . 44
   B.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . . 45
   B.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . . 46
   B.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . . 47
   B.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 47
   B.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 48
   B.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . . 49
   C.    Authentication Examples  . . . . . . . . . . . . . . . . . . 51
   C.1   Authenticating An Answer . . . . . . . . . . . . . . . . . . 51
   C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 51
   C.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 52
   C.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . . 52
   C.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . . 52
   C.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . . 52
   C.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 53
   C.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 53
   C.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . . 53
         Intellectual Property and Copyright Statements . . . . . . . 54

1. Introduction

   The DNS Security Extensions (DNSSEC) are a collection collection of new resource
   records and protocol modifications which 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 to handle signed zones. Section 4 describes
   the behavior of entities which include security-aware resolver
   functions. Finally, Section 5 defines how to use DNSSEC RRs to
   authenticate a response.

1.1 Background and Related Documents

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

   This document is part of a family of documents which define DNSSEC.
   An introduction to DNSSEC and definition of common terms can be found
   in [I-D.ietf-dnsext-dnssec-intro].  A definition of the DNSSEC
   resource records can be found in [I-D.ietf-dnsext-dnssec-records].

1.2 Reserved Words

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

1.3 Editors' Notes

1.3.1 Open Technical Issues

1.3.2 Technical Changes or Corrections

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

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

1.3.3 Typos and Minor Corrections

   Please report any typos corrections to dnssec-editors@east.isi.edu.
   To assist the editors, please provide enough context for us to find
   the incorrect text quickly.

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

2. Zone Signing

   DNSSEC is built around the concept of new resource signed zones.  A signed zone
   includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
   the rules specified in Section 2.1, Section 2.2, Section 2.3 and protocol modifications
   Section 2.4, respectively.  Any zone which add data origin
   authentication and data integrity does not include these
   records according to the DNS. This document defines rules in this section MUST be considered
   unsigned for the purposes of the DNS security extensions.

   DNSSEC protocol modifications. requires a change to the definition of the CNAME resource
   record.  Section 2 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs
   to appear at the same owner name as a CNAME RR.

   Section 2.6 shows a sample signed zone.

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, there SHOULD be a corresponding zone DNSKEY RR
   stored in the zone.  A zone key DNSKEY RR has the Zone Key bit of this document defines the concept of a signed
   flags RDATA field set to one -- see Section 2.1.1 of
   [I-D.ietf-dnsext-dnssec-records].  Public keys associated with other
   DNS operations MAY be stored in DNSKEY RRs that are not marked as
   zone keys.

   If the zone is delegated and lists does not wish to act as an island of
   security, the requirements for zone
   signing. Section 3 describes MUST have at least one DNSKEY RR at the modifications to authoritative name
   server behavior necessary apex to handle signed zones. Section 4 describes
   act as a secure entry point into the behavior of entities which include security-aware resolver
   functions. Finally, Section 5 defines how zone.  This DNSKEY would then be
   used to use DNSSEC generate a DS RR at the delegating parent (see
   [I-D.ietf-dnsext-dnssec-records]).  This DNSKEY RR SHOULD be either a
   zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro]
   for definition).

   DNSKEY RRs to
   authenticate MUST NOT appear at delegation points.

2.2 Including RRSIG RRs in a response.

1.1 Background Zone

   For each authoritative RRset in a signed zone (which excludes both NS
   RRsets at delegation points and Related Documents glue RRsets), there MUST be at least
   one RRSIG record that meets all of the following requirements:

   o  The reader RRSIG owner name is assumed equal to be familiar with the basic DNS concepts
   described in RFC1034 [RFC1034] and RFC1035 [RFC1035].

   This document RRset owner name;

   o  The RRSIG class is part of a family of documents which define DNSSEC.
   An introduction equal to DNSSEC and definition of common terms can be found
   in [I-D.ietf-dnsext-dnssec-intro].  A definition of the DNSSEC
   resource records can be found in [I-D.ietf-dnsext-dnssec-records].

1.2 Reserved Words RRset class;

   o  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are RRSIG Type Covered field is equal to the RRset type;
   o  The RRSIG Original TTL field is equal to be interpreted as described in RFC 2119. [RFC2119].

1.3 Editors' Notes

1.3.1 Open Technical Issues

1.3.2 Technical Changes or Corrections

   Please report technical corrections the TTL of the RRset;

   o  The RRSIG RR's TTL is equal to dnssec-editors@east.isi.edu.
   To assist the editors, please indicate TTL of the text RRset;

   o  The RRSIG Labels field is equal to the number of labels in error the
      RRset owner name, not counting the null root label and point
   out not
      counting the RFC that defines wildcard label if the correct behavior.  For owner name is a technical
   change where no RFC that defines wildcard;

   o  The RRSIG Signer's Name field is equal to the correct behavior, or if there's
   more than one applicable RFC name of the zone
      containing the RRset; and

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

   The process for constructing the issue to namedroppers. RRSIG RR for a given RRset is
   described in [I-D.ietf-dnsext-dnssec-records]. An example correction to dnssec-editors might be: Page X says
   "DNSSEC RRset MAY have
   multiple RRSIG RRs SHOULD associated with it.

   An RRSIG RR itself MUST NOT be automatically returned in responses."  This was
   true signed, since signing an RRSIG RR
   would add no value and would create an infinite loop in RFC 2535, the signing
   process.

   The NS RRset which appears at the zone apex name MUST be signed, but RFC 3225 (Section 3, 3rd paragraph) says
   the
   DNSSEC RR types NS RRsets which appear at delegation points (that is, the NS
   RRsets in the parent zone which delegate the name to the child zone's
   name servers) MUST NOT be included signed. Glue address RRsets associated with
   delegations MUST NOT be signed.

   There MUST be an RRSIG for each RRset generated using at least one
   DNSKEY of each algorithm in responses unless the resolver
   indicated support for DNSSEC.

1.3.3 Typos parent zone's DS RRset and Minor Corrections

   Please report any typos corrections to dnssec-editors@east.isi.edu.
   To assist the editors, please provide enough context for us to find each
   additional algorithm, if any, in the incorrect text quickly.

   An example message to dnssec-editors might be: page X says "the
   DNSSEC standard has been apex DNSKEY RRset.  The apex
   DNSKEY RRset itself MUST be signed by each algorithm appearing in development for over 1 years".   It
   should read "over 10 years".

2. Zone Signing

   DNSSEC is built around the concept
   DS RRset.

   The difference between the set of signed zones.  A signed zone
   includes DNSKEY, RRSIG, owner names which require RRSIG
   records and the set of owner names which require NSEC records is
   subtle and (optionally) DS worth highlighting.  RRSIG records according to are present at the rules specified in Section 2.1, Section 2.2, Section 2.3 and
   Section 2.4, respectively.  Any zone which does not include these
   owner names of all authoritative RRsets.  NSEC records according to are present at
   the rules in this section MUST be considered
   unsigned owner names of all names for which the purposes signed zone is
   authoritative and also at the owner names of delegations from the DNS security extensions.

   DNSSEC requires a change
   signed zone to its children.  Neither NSEC nor RRSIG records are
   present (in the definition parent zone) at the owner names of glue address
   RRsets.  Note, however, that this distinction is for the CNAME resource
   record.  Section 2.5 changes most part
   only visible during the CNAME RR to allow RRSIG and zone signing process, because NSEC RRs
   to appear at the same RRsets are
   authoritative data, and are therefore signed, thus any owner name
   which has an NSEC RRset will have RRSIG RRs as a CNAME RR.

   Section 2.6 shows a sample well in the signed
   zone.

2.1

2.3 Including DNSKEY NSEC 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, there SHOULD be a corresponding zone DNSKEY RR
   stored

   Each owner name in the zone.  A zone key DNSKEY RR has the Zone Key bit of MUST have an NSEC resource record, except
   for the
   flags RDATA field set to one -- see Section 2.1.1 owner names of
   [I-D.ietf-dnsext-dnssec-records].  Public keys associated with other
   DNS operations MAY be stored in DNSKEY RRs that are not marked as
   zone keys.

   If any glue address RRsets.  The process for
   constructing the zone NSEC RR for a given name is delegated and does not wish to act as an island described in
   [I-D.ietf-dnsext-dnssec-records].

   The type bitmap of
   security, the every NSEC resource record in a signed zone MUST have at least one DNSKEY RR at
   indicate the apex to
   act as a secure entry point into presence of both the zone.  This DNSKEY would then be
   used to generate NSEC record itself and its
   corresponding RRSIG record.

2.4 Including DS RRs in a Zone

   The DS RR at the delegating parent (see
   [I-D.ietf-dnsext-dnssec-records]).  This DNSKEY RR resource record establishes authentication chains between DNS
   zones.  A DS RRset SHOULD be either present at a delegation point when the
   child zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro]
   for definition). is signed.  The DNSKEY DS RRset at MAY contain multiple records,
   each referencing a key used by the child zone to sign its apex DNSKEY
   RRset.  All DS RRsets in a zone MUST be signed by
   at least one zone signing or DNSKEY signing private key.

   DNSKEY RRs and DS RRsets MUST NOT
   appear at delegation points.

2.2 Including RRSIG RRs in a Zone

   For each authoritative RRset in a signed zone (which excludes both NS
   RRsets at delegation non-delegation points and glue RRsets), there MUST be nor at least
   one RRSIG record that meets all of the following requirements:

   o  The RRSIG owner name is equal a zone's apex.

   A DS RR SHOULD point to the RRset owner name;

   o  The RRSIG class a DNSKEY RR which is equal to present in the RRset class;
   o  The RRSIG Type Covered field is equal to child's
   apex DNSKEY RRset, and the child's apex DNSKEY RRset type;

   o  The RRSIG Original TTL field is equal to the TTL of SHOULD be signed
   by the RRset;

   o corresponding private key.

   The RRSIG RR's TTL is equal to of a DS RRset SHOULD match the TTL of the RRset;

   o  The RRSIG Labels field is equal to the number corresponding NS
   RRset.

   Construction of a DS RR requires knowledge of labels in the
      RRset owner name, not counting the null root label and not
      counting corresponding
   DNSKEY RR in the wildcard label if child zone, which implies communication between the owner name is a wildcard;

   o  The RRSIG Signer's Name field
   child and parent zones.  This communication is equal 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 of the zone
      containing the RRset; and

   o  The in a signed zone, appropriate
   RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
      zone key DNSKEY record NSEC RRsets are REQUIRED at that name. Other types MUST NOT
   be present at that name.

   This is a modification to the zone apex. original CNAME definition given in
   [RFC1034].  The process for constructing original definition of the RRSIG CNAME RR for did not allow any
   other types to coexist with a given RRset is
   described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
   multiple CNAME record, but a signed zone
   requires NSEC and RRSIG RRs associated for every authoritative name.  To resolve
   this conflict, this specification modifies the definition of the
   CNAME resource record to allow it to coexist with it.

   An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
   would add no value NSEC and would create an infinite loop in RRSIG RRs.

2.6 Example of a Secure Zone

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

3. Serving

   This section describes the signing
   process.

   The NS RRset behavior of entities which appears at the zone apex include
   security-aware name MUST functions.  In many cases such functions will be signed,
   part of a security-aware recursive name server, but a security-aware
   authoritative name server has some of the NS RRsets which appear at delegation points (that is, the NS
   RRsets in the parent zone which delegate the same requirements as a
   security-aware recursive name server does. Functions specific to the child zone's
   security-aware recursive name servers) MUST NOT be signed. Glue address RRsets associated with
   delegations MUST NOT be signed. servers are described in Section 3.2;
   functions specific to authoritative servers are described in Section
   3.1.

   The difference between the set of owner names which require RRSIG
   records terms "SNAME", "SCLASS", and "STYPE" in the set of owner names which require NSEC records is
   subtle and worth highlighting.  RRSIG records following discussion
   are present at as used in [RFC1034].

   A security-aware name server MUST support the
   owner names EDNS0 [RFC2671] message
   size extension, MUST support a message size of all authoritative RRsets.  NSEC records are present at
   the owner names least 1220 octets,
   and SHOULD support a message size of all names for 4000 octets [RFC3226].

   A security-aware name server which receives a DNS query which does
   not include the signed zone is
   authoritative and also at the owner names of delegations from EDNS OPT pseudo-RR or which has the
   signed zone DO bit set to its children.  Neither
   zero MUST treat the RRSIG, DNSKEY, and NSEC nor RRSIG records are
   present (in RRs as it would any other
   RRset, and MUST NOT perform any of the parent zone) at additional processing
   described below.  Since the owner names of glue address
   RRsets.  Note, however, that this distinction is for DS RR type has the most part peculiar property of
   only visible during existing in the parent zone signing process, because NSEC RRsets are
   authoritative data, and are therefore signed, thus any owner name
   which has an NSEC RRset will have RRSIG at delegation points, DS RRs always
   require some special processing, as well described in the signed
   zone.

2.3 Including NSEC RRs Section 3.1.4.1.

   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 Zone

   Each owner security-aware name in server MUST copy
   the zone CD bit from a query into the corresponding response.  The AD bit
   is controlled by name servers; a security-aware name server MUST have an NSEC resource record, except
   for
   ignore the owner names setting of any glue address RRsets.  The process for
   constructing the NSEC RR AD bit in queries.  See Section 3.1.6,
   Section 3.2.2, Section 3.2.3, Section 4, and Section 4.2 for details
   on the behavior of these bits.

3.1 Authoritative Name Servers

   Upon receiving a given relevant query which has the EDNS [RFC2671] OPT
   pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
   name is described in
   [I-D.ietf-dnsext-dnssec-records].

   The type bitmap of every NSEC resource record in server for a signed zone MUST
   indicate include additional RRSIG, NSEC,
   and DS RRs according to the presence of both following rules:

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

   o  NSEC record itself and its
   corresponding RRSIG record.

2.4 Including DS RRs which 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 Zone

   The DS resource record establishes authentication chains between DNS
   zones.  A DS RRset SHOULD or an NSEC RR proving that no DS RRs exist MUST
      be present at a delegation point when included in referrals automatically according to the rules in
      Section 3.1.4.

   DNSSEC does not change the
   child DNS zone is signed.  The DS RRset MAY contain multiple records,
   each referencing a key used by the child transfer protocol.  Section 3.1.5
   discusses zone to sign its apex DNSKEY
   RRset.  All DS RRsets transfer requirements.

3.1.1 Including RRSIG RRs in a zone MUST be signed and DS RRsets MUST NOT
   appear at non-delegation points nor at a zone's apex.

   A DS RR SHOULD point Response

   When responding to a DNSKEY RR query which is present in the child's
   apex DNSKEY RRset, and has the child's apex DNSKEY RRset DO bit set to one, a
   security-aware authoritative name server SHOULD be signed
   by the corresponding private key.

   Construction of attempt to send RRSIG
   RRs which a DS RR requires knowledge of security-aware resolver can use to authenticate the corresponding
   DNSKEY RR
   RRsets in the child zone, which implies communication between the
   child and parent zones.  This communication response.  Inclusion of RRSIG RRs in a response is an operational matter
   not covered by this document.

2.5 Changes
   subject to the CNAME Resource Record.

   If following rules:

   o  When placing a CNAME signed RRset is present at a in the Answer section, the name server
      MUST also place its RRSIG RRs in a signed zone, appropriate the Answer section.  The RRSIG and NSEC
      RRs have a higher priority for inclusion than any other RRsets are REQUIRED at that name. Other types MUST NOT
      which may need to be present at that name.

   This is included.  If space does not permit inclusion
      of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a modification to signed RRset in the original CNAME definition given Authority section, the name
      server MUST also place its RRSIG RRs in
   [RFC1034].  The original definition of the CNAME RR did not allow Authority section.
      The RRSIG RRs have a higher priority for inclusion than any other types
      RRsets that may need to co-exist with a CNAME record, but 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 zone
   requires NSEC and RRset in the Additional section, the name
      server MUST also place its RRSIG RRs for every authoritative name.  To resolve
   this conflict, this specification modifies in the definition Additional section.
      If space does not permit inclusion of these RRSIG RRs, the
   CNAME resource record to allow it to co-exist with NSEC and name
      server MUST NOT set the TC bit solely because these RRSIG
   RRs.

2.6 Example of RRs
      didn't fit.

3.1.2 Including DNSKEY RRs In a Secure Zone

   Appendix B shows Response

   When responding to a complete example query which has the DO bit set to one and which
   requests the SOA or NS RRs at the apex of a small signed zone.

3. Serving

   This section describes the behavior of zone, a
   security-aware authoritative name server.  A security-aware authoritative name server MUST support for that zone MAY return the EDNS0 [RFC2671] message size extension, MUST support a message
   size of at least 1220 octets,
   zone apex DNSKEY RRset in the Additional section.  In this situation,
   the DNSKEY RRset and SHOULD support a message size of
   4000 octets [RFC3226].  Since functions specific to security-aware
   recursive associated RRSIG RRs have lower priority than
   any other information that would be placed in the additional section.
   The name servers included components of server SHOULD NOT include the DNSKEY RRset unless there is
   enough space in the response message for both resolving the DNSKEY RRset and
   serving, issues specific
   its associated RRSIG RR(s). If there is not enough space to security-aware recursive include
   these DNSKEY and RRSIG RRs, the name servers are
   described in server MUST omit them and MUST
   NOT set the TC bit solely because these RRs didn't fit (see Section 4.

   Upon receiving
   3.1.1).

3.1.3 Including NSEC RRs In a Response

   When responding to a relevant query which has the EDNS [RFC2671] OPT
   pseudo-RR DO bit [RFC3225] set to one, 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 which can be used to authenticate a response MUST be
      included in the response according to the rules in Section 3.1;

   o  NSEC RRs which can be used to provide authenticated denial of
      existence MUST be included in the response automatically according
      to the rules in Section 3.3;

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

   DNSSEC following cases:

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

   Name Error: The zone transfer protocol.  Zone transfer
   requirements are reviewed in Section 3.6.

   A security-aware does not contain any RRsets which match <SNAME,
      SCLASS> either exactly or via wildcard name server expansion.

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

   Wildcard No Data: The zone does not include the EDNS OPT pseudo-RR or which has the DO bit set to
   zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would contain any other
   RRset, and MUST NOT perform RRsets which exactly
      match <SNAME, SCLASS>, does contain one or more RRsets which
      matches <SNAME, SCLASS> via wildcard name expansion, but does not
      contain any RRsets which match <SNAME, SCLASS, STYPE> via wildcard
      name expansion.

   In each of these cases, the additional processing
   described above.  Since the DS RR type has name server includes NSEC RRs in the peculiar property of
   only existing
   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
   not present in the parent zone at delegation points, DS RRs always
   require some special processing, as described in Section 3.5.

3.1 Including RRSIG RRs in a Response

   When a query has and that the DO bit set to one, response which the authoritative name server
   SHOULD attempt to send RRSIG RRs which can be used to authenticate
   is returning is correct given the RRsets data which are in the response.  Inclusion of RRSIG RRs in a response is
   subject to zone.

3.1.3.1 Including NSEC RRs: No Data Response

   If the following rules:

   o  When placing a signed zone contains RRsets matching <SNAME, SCLASS> but contains no
   RRset in the Answer section, matching <SNAME, SCLASS, STYPE>, then the name server MUST also place
   include the NSEC RR for <SNAME, SCLASS> along with its associated
   RRSIG RRs RR(s) in the Answer section.  The RRSIG
      RRs have a higher priority for inclusion than any other RRsets
      which may need to be included. Authority section of the response (see Section
   3.1.1).  If space does not permit inclusion of these the NSEC RR or its
   associated RRSIG RRs, 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 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 server MUST set the TC bit.

   o  When placing a signed RRset in the Authority section, expansion, then the name server
   MUST also place its RRSIG include the following NSEC RRs in the Authority section.
      The section, along
   with their associated RRSIG RRs have a higher priority RRs:

   o  An NSEC RR proving that there is no exact match for inclusion than any other
      RRsets <SNAME,
      SCLASS>; and

   o  An NSEC RR proving that may need to be included.  If space does not permit
      inclusion of these RRSIG RRs, the zone contains no RRsets which would
      match <SNAME, SCLASS> via wildcard name server MUST set the TC bit.

   o  When placing expansion.

   In some cases a signed RRset single NSEC RR may prove both of these points, in the Additional section,
   which case the name server MUST also place SHOULD only include the NSEC RR and its
   RRSIG RRs RR(s) once in the Additional Authority section.

   If space does not permit inclusion of these NSEC and RRSIG RRs, the
   name server MUST NOT set the TC bit solely because these RRSIG RRs
      didn't fit.

3.2 (see Section 3.1.1).

3.1.3.3 Including DNSKEY RRs In a NSEC RRs: Wildcard Answer Response

   When a query has the DO bit set to one and requests the SOA or NS RRs
   at

   If the apex of a signed zone, a security-aware authoritative name
   server for that zone MAY return the DNSKEY does not contain any RRsets which exactly match <SNAME,
   SCLASS> but does contain an RRset with the same which matches <SNAME, SCLASS,
   STYPE> via wildcard name
   in the Additional section.  In this situation, the DNSKEY RR set and
   associated RRSIG RRs have lower priority than any other information
   that would be placed in expansion, the additional section.  The name server
   should MUST include the DNSKEY RRset if and only if there is enough space
   wildcard-expanded answer and the corresponding wildcard-expanded
   RRSIG RRs in the response for both Answer section, and MUST include in the DNSKEY RRset Authority
   section an NSEC RR and associated RRSIG RR(s).
   If there is RR(s) proving that the zone
   does not enough contain a closer match for <SNAME, SCLASS>.  If space to include does
   not permit inclusion of these DNSKEY answer, NSEC and RRSIG RRs, the name
   server MUST omit them and MUST NOT set the TC bit solely
   because these RRs didn't fit.

3.3 (see Section 3.1.1).

3.1.3.4 Including NSEC RRs In a RRs: Wildcard No Data Response

   When

   This case is a query has combination of the DO bit set to one, security-aware authoritative
   name servers previous cases.  The zone does not
   contain an exact match for a signed <SNAME, SCLASS>, and while the zone does
   contain RRsets which match <SNAME, SCLASS> via wildcard name
   expansion, none of those RRsets match STYPE.  The name server MUST
   include the following NSEC RRs in each of the
   following cases:

   Case 1: The QNAME has RRsets associated Authority section, along with it in the zone, but the
      requested
   their associated RRSIG RRs:

   o  An NSEC RR type does not exist.

   Case 2: The QNAME, QTYPE, QCLASS tuple does not exist, and proving that there are no
      wildcard can be expanded to answer RRsets matching STYPE at the query.

   Case 3: The QNAME (or search name) does not exist, but a
      wildcard can
      be expanded to positively answer the query.

   Note that, in each case, a set of owner name which matched <SNAME, SCLASS> via wildcard
      expansion; and

   o  An NSEC RRs is included to provide
   authenticated denial of existence.

3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not Present

   If proving that there are RR types associated with a given QNAME, but no RRsets in the
   requested zone which
      would have been a closer match for <SNAME, SCLASS>.

   In some cases a single NSEC RR type is not present at the name, then may prove both of these points, in
   which case the name server
   MUST SHOULD only include the NSEC RR associated with the query name and any its
   RRSIG
   RRs associated with the NSEC RR RR(s) once in the Authority section (see Section
   3.1). section.

   If space does not permit inclusion of the these NSEC RR or its
   associated and RRSIG RRs, the
   name server MUST set the TC bit.

   Note that, since the query 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 exists, no wildcard expansion applies server needs to this query, and a single locate an NSEC RR suffices to prove the requested
   RR type
   which proves that a particular SNAME does not exist.

3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches

   If  Locating such
   an NSEC RR within an authoritative zone is relatively simple, at
   least in concept.  The following discussion assumes that the query name
   server is authoritative for the zone which would have held the
   nonexistent SNAME.  The algorithm below is written for clarity, not
   efficiency.

   To find the NSEC which proves that name N does not exist in the zone, and no wildcard
   expansion matches both the query zone
   Z which would have held it, construct sequence S consisting of every
   name and in Z, sorted into canonical order.  Find the query type, name M which would
   have immediately preceded N in S if N had existed.  M is the owner
   name
   server MUST include of the following NSEC RRs in RR which proves that N does not exist.

   The algorithm for finding the Authority section,
   along with their associated RRSIG RRs:

   o  An NSEC RR proving which proves that there was no exact match a given name
   is not covered by any applicable wildcard is similar, but requires an
   extra step.  More precisely, the algorithm for finding the name; and

   o  An NSEC RR combination
   proving that there was no the applicable wildcard which
      would have matched name does not exist is precisely
   the query.  See [I-D.ietf-dnsext-wcard-clarify] same as the algorithm for further information on finding the NSEC coverage.

   If space RR which proves that
   any other name does not permit inclusion exist: the part that's missing is how to
   determine the name of these NSEC and RRSIG RRs, the nonexistent applicable wildcard.  In
   practice, this is easy, because the authoritative name server MUST set has
   already checked for the TC bit (see Section 3.1).

   Appendix A provides an algorithm which computes presence of precisely this wildcard name as
   part of step (1)(c) of the appropriate NSEC normal lookup algorithm described in
   Section 4.3.2 of [RFC1034].

3.1.4 Including DS RRs In a Response

   When responding to prove that no wildcard matches a given query name.

3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches

   If which has the query DO bit set to one, a
   security-aware authoritative name does not exist, but server returning a wildcard expansion can be
   used to return referral
   includes DNSSEC data along with the NS RRset.

   If a positive match to DS RRset is present at the query, delegation point, the name server
   MUST
   include return both the wildcard-expanded answer DS RRset and the corresponding
   wildcard-expanded its associated RRSIG RRs in RR(s) along
   with the Answer section. NS RRset.  The Authority
   section of the response name server MUST include place the following NSEC RRs along
   with their corresponding NS RRset before
   the DS RRset and its associated RRSIG RRs:

   o  An RR(s).

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR which proves that there were no exact matches for the
      QNAME and QTYPE; DS RRset is not
   present and

   o  An the NSEC RR combination which proves that there are no closer
      wildcard entries which could have been expanded 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 match the
      query.  See [I-D.ietf-dnsext-wcard-clarify] for further
      information on NSEC coverage. be omitted.

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

   Appendix A provides an algorithm which computes the appropriate NSEC
   RRs 3.1.1).

3.1.4.1 Responding to prove that no closer wildcard matches the query name.

3.4 Including Queries for DS RRs In a Response

   When

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a query has zone cut.  For example, the DO bit set to one, 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, since 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.

   A security-aware resolver will send queries to the parent zone when
   looking for a DS RR exists RRset at a delegation point, and thus will never
   trigger the
   query name, an authoritative corresponding special processing in a security-aware name
   server.   The rest of this section describes how a security-aware
   recursive name server returning processes a
   referral misdirected DS query.

   The need for special processing by a security-aware name server only
   arises when:

   o  the delegation MUST include both name server has received a query for the NS 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; and also

   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 and its associated RRSIG RR(s).  The
   even by the pre-DNSSEC processing rules, so the name server MUST
   place the NS RRset before can
   return either the DS RRset and its associated RRSIG RRs.

   When a query has the DO bit set or an error response according to one, and no DS RR exists at the
   query name, an authoritative security-aware
   normal processing rules.

   If all of the above conditions are met, however, the name server returning a
   referral is
   authoritative for SNAME but cannot supply the delegation MUST include both the NS RRset and also requested RRset.  In
   this case, the NSEC RR and associated RRSIG RR(s) which proves name server MUST return an authoritative "no data"
   response showing that the DS RRset does not exist.  The name server MUST place the NS RRset before the
   NSEC RRset and its associated RRSIG RR(s).

   Including these DS and RRSIG RRs increases exist in the size child zone's
   apex.  See Appendix B.8 for an example of referral
   messages, and may cause some or all glue RRs such a response.

3.1.5 Responding to be omitted.  If space Queries for Type AXFR or IXFR

   DNSSEC does not permit inclusion of change the DNS zone transfer process.  A signed zone
   will contain RRSIG, DNSKEY, NSEC, and DS or NSEC RRset resource records, but these
   records have no special meaning with respect to a zone transfer
   operation, and associated
   RRSIG RRs, the these RRs are treated as any other resource record
   type.

   An authoritative name server MUST set 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 meets any of the TC bit.

   Security-aware name servers also include NSEC RRs signing requirements
   described in Section 2.  The primary objective of a referral
   response when no DS RR zone transfer is present; in this case, the NSEC RR proves
   to ensure that no DS RR exists for all authoritative name servers have identical copies
   of the delegation. Section 3.4 discusses
   referrals in more detail.

3.5 Responding zone.  An authoritative name server which chooses to Queries for DS perform
   its own zone validation MUST NOT selectively reject some RRs

   The and
   accept others.

   DS resource record type is unusual in that it appears RRsets appear only on the
   parent zone's parental side of a zone cut.  In cut and are
   authoritative data in the parent zone.  As with any other words,
   authoritative RRset, the DS record for
   the delegation RRset MUST be included in zone transfers
   of "example.com" the zone in which the RRset is only stored authoritative data: in the "com" zone.
   This introduces novel name server behavior, since case of
   the name server for DS RRset, this is the parent zone.

   NSEC RRs appear in both the parent and child zones at a zone is cut, and
   are authoritative for data in both the name by parent and child zones.  The
   parental and child NSEC RRs at a zone cut are never identical to each
   other, since the normal DNS rules
   but NSEC RR in the child zone's apex will always
   indicate the presence of the child zone's SOA RR while the parental
   NSEC RR at the zone does not contain cut will never indicate the DS presence of an SOA
   RR.  An authoritative name
   server's response to a DS query depends on whether the name server is  As with any other authoritative for RRs, NSEC RRs MUST be included
   in zone transfers of the parent zone, zone in which they are authoritative data:
   the child zone, or both, as
   described below.

   If parental NSEC RR at a name server is authoritative for zone cut MUST be included zone transfers of
   the parent zone, and receives a
   query for while the DS record NSEC at the delegated name, then zone apex of the name server child zone
   MUST return the DS RRset from the parent zone.  This rule applies
   regardless be included in zone transfers of whether or not the name server is also authoritative
   for the child zone.

   If

   RRSIG RRs appear in both the name server is parent and child zones at a zone cut,
   and are authoritative for in whichever zone contains the child zone, is not authoritative
   RRset for which the parent zone, and receives a query for RRSIG RR provides the signature.  That is, the
   RRSIG RR for a DS
   record RRset or a parental NSEC RR at the delegated name, there is no obvious response, because
   the child a zone is not cut will be
   authoritative for in the DS record at parent zone, while the RRSIG for any RRset in
   the child zone's apex, and apex will be authoritative in the child zone. As
   with any other authoritative DS RR is only stored at RRs, RRSIG RRs MUST be included in zone
   transfers of the
   parent.

   If 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 to be used in communication between
   security-aware resolvers and security-aware recursive name servers.
   This bits are for the most part not relevant to query processing by
   security-aware authoritative name servers.

   Since a security-aware name server allows recursion, and does not perform signature
   validation for authoritative data during query processing even when
   the RD CD bit is set in the
   query, the name server MAY perform recursion to find the DS record
   for the delegated zero, a security-aware name from the parent zone, and MAY return server SHOULD ignore
   the DS
   record from its cache.  In this case, setting of the AA CD bit when composing an authoritative response.

   A security-aware name server MUST NOT be set in the response.

   If AD bit in a response
   unless the name server does not perform recursion to find the DS RR, considers all RRsets in the
   name server MUST reply with:

         RCODE:             NOERROR
         AA bit:            set Answer Section:    Empty or
   Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)]

   In other words, a sections of the response to be authentic.  A security-aware
   name server which is server's local policy MAY consider data from an authoritative for the child
   zone to be authentic without further validation, but not for the parent zone answers as if name server
   MUST NOT do so unless the DS record does not
   exist.  Note that security-aware resolvers will query name server obtained the parent authoritative zone
   at delegation points, and thus will not be affected by this behavior.

   For example, suppose that "example.com" is
   via secure means (such as a delegation point, secure zone transfer mechanism), and a MUST
   NOT do so unless this behavior has been configured explicitly.

   A security-aware name server receives a query for the "example.com" DS RRset.

   o  If which supports recursion MUST follow the name server is authoritative
   rules for "com", 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 [I-D.ietf-dnsext-dnssec-intro], a security-aware
   recursive name server
      MUST reply with the "example.com" DS RRset from the "com" zone.

   o  If is an entity which acts in both the
   security-aware name server is authoritative for "example.com", is not
      authoritative for "com", and security-aware resolver roles. This
   section uses the RD bit is set terms "name server side" and "resolver side" to
   refer to one in the
      query, code within a security-aware recursive name server which
   implements the security-aware name server MAY perform recursion to find role and the
      "example.com" DS record.  If code which
   implements the security-aware resolver role, respectively.

   A security-aware recursive name server does not use
      recursion MUST NOT attempt to obtain the DS RR, the answer a
   query by piecing together cached data it received in response to
   previous queries that requested different QNAMEs, QTYPEs, or
   QCLASSes.  A security-aware recursive name server MUST reply as
      though the DS RR did not exist:

            RCODE:             NOERROR
            AA bit:            set
            Answer Section:    Empty
            Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)]

3.6 Responding NOT use NSEC
   RRs from one negative response to Queries synthesize a response for Type AXFR or IXFR

   DNSSEC does not change the DNS zone transfer process. a
   different query.  A signed zone
   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
   records have no special meaning with respect security-aware recursive name server MUST NOT use
   a previous wildcard expansion to generate a zone transfer
   operation, response to a different
   query.

   The resolver side MUST follow the usual rules for caching and these RRs are treated as
   negative caching which would apply to any other resource record
   type.

   An authoritative security-aware resolver.

3.2.1 The DO bit

   The resolver side of a security-aware recursive name server is not required to verify that a zone is
   properly signed before MUST set
   the DO bit when sending or accepting a zone transfer.
   However, 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 authoritative initiating query is not set, the name server MAY choose to reject the entire
   zone transfer if side
   MUST strip any authenticating DNSSEC RRs from the zone fails meets response, but but
   MUST NOT strip any of DNSSEC RRs that the signing requirements
   described in Section 2. initiating query explicitly
   requested.

3.2.2 The primary objective 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 zone transfer particular query.  This is
   to ensure a useful but somewhat
   dangerous capability that all authoritative requires careful handling by security-aware
   recursive name servers have identical copies
   of the zone.  An authoritative servers.

   A security-aware recursive name server which chooses to perform
   its own zone validation MUST NOT selectively reject some RRs and
   accept others.

   Note that disregard the DS RR appears only in CD bit and
   perform normal signature validation unless:

   o  the parental name server side of received that query via a delegation
   and is authoritative data in secure channel; or

   o  the parent zone. For example, recursive name server's local policy dictates that the DS RR
   for "example.com" is stored in
      recursive name server honor the "com" zone (the parent zone)
   rather than CD bit even when received via an
      insecure channel.

   Discussion of cases in which the "example.com" zone (the child zone).  As with any
   other authoritative RRset, the "example.com" DS RR MUST be included
   the "com" zone transfer.

   Note that authoritative NSEC RRs appear CD bit is set to one in both the parent and child
   zones at a delegated name, and rest of
   this section assumes that one or both of the NSEC RRs for the delegated
   name in the parent and child zones are never identical above conditions applies
   to each other.
   As with any other authoritative RRset, the parental NSEC RR at a
   delegated query being processed.  If neither condition applies, the
   recursive name server MUST be included zone transfers of the parent zone,
   while process the NSEC at query as if the zone apex of CD bit were
   set to zero. Note, however, that the child zone name server side MUST be included in
   zone transfers of always
   copy the child zone.

3.7 Setting setting of the AD and CD Bits in a Response

      Editors' note: This section seems bit from a little lost here. Perhaps we
      should rearrange query to the section ordering slightly, corresponding
   response, regardless of whether or provide a
      pointer to this subsection at not the recursive name server
   trusts the beginning setting of Section 3.

   DNSSEC allocates two new bits in the DNS message header: The CD
   (Checking Disabled) bit and the AD (Authentic Data) bit.

   The name server side of a security-aware recursive name server MUST
   pass the sense of the CD bit is set in query messages by to the resolver, and MUST be
   copied into resolver side along with the rest
   of an initiating query, so that the resolver side will know whether
   or not it is required to verify the response by data it returns to the
   name server. server side. If the CD bit is set to one, it indicates that the
   originating resolver is willing to perform whatever authentication
   its local policy requires, and thus that the resolver side of the recursive
   name server need not perform authentication on the RRsets in the
   response.

   Regardless of the setting of the CD bit, the name server MAY choose
   whether or not to perform authentication according to its own local
   name server policy, and the name server MAY use  When the CD bit as input
   to its own local policy.  However, if the resolver has is set to one the CD
   bit, a 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 taken 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.1) and the
   name server side receives a query which matches an entry in the
   resolver side's BAD cache, the name server should not interfere side's response depends on
   the sense of the CD bit in this
   case.

   The AD the original query.  If the CD bit is set by set,
   the name servers, and indicates server side SHOULD return the data in from the
   response has been authenticated by BAD cache; if
   the name server, according to CD bit is not set, the
   local name server policy. side MUST return RCODE 2
   (server failure).

3.2.3 The AD bit

   The name server side of a security-aware recursive name server MUST
   NOT be set on the AD bit in a response unless the name server considers all
   RRsets in the Answer or Authority sections of the response to be
   authentic, and 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 sections have
   met section to be authentic.  The resolver
   side MUST follow the procedure described in Section 5 to determine
   whether the RRs in question are authentic.

3.3 Example DNSSEC Responses

   See Appendix B for example response packets.

4. Resolving

   This section describes the behavior of entities which 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.

   A security-aware resolver MUST include an EDNS [RFC2671] OPT
   pseudo-RR with the DO [RFC3225] bit set to one 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
   advertise the supported message size using the "sender's UDP payload
   size" field in the name server's local authentication policy. EDNS OPT pseudo-RR. A security-aware resolver MUST
   NOT trust the AD bit unless it communicates with
   handle fragmented UDP packets correctly regardless of whether any
   such fragmented packets were received via IPv4 or IPv6.  Please see
   [RFC3226] for discussion of these requirements.

   A security-aware resolver MUST support the name server over
   a secure transport mechanism signature verification
   mechanisms described in Section 5, and is explicitly configured MUST apply them to trust
   the every
   received response except when:

   o  The security-aware resolver is part of a security-aware recursive
      name server's policy.

3.8 Example DNSSEC Responses

      Editors' note: these examples probably ought to move to an
      appendix server, and probably ought to use the "real" signed example zone
      that's already in an appendix.

   The examples in this section use the following example zone to
   demonstrate response is the formation result of recursion on behalf
      of replies by an authoritative name server.
   The zone has two name servers, a single child, and a wildcard MX RR. query received with the CD bit set;

   o  The zone response is completely signed and has a full NSEC chain.

      example.com.    SOA     (...)
                      RRSIG     SOA ...
                      NS      a.example.com.
                      NS      b.example.com.
                      RRSIG     NS ...
                      MX      10 a.example.com
                      RRSIG     MX ...
                      DNSKEY     ...
                      RRSIG     DNSKEY ...
                      NSEC     *.example.com.
      *               MX      10 a.example.com.
                      RRSIG     MX ...
                      NSEC     a.example.com. the result of a               A       10.10.10.1
                      RRSIG     A ...
                      NSEC     b.example.com.
      b               A       10.10.10.2
                      RRSIG     A ...
                      NSEC     c.example.com.
      c               CNAME   a.example.com.

                      RRSIG     CNAME
                      NSEC     sub.example.com.
      sub             NS      ns.sub.example.com.
                      RRSIG     NS
                      DS      ...
                      RRSIG     DS
                      NSEC     *.example.com.
      ns.sub          A       10.10.10.3
      sub-nosig       NS      ns.sub-nosig.example.com.
                      NSEC     example.com.
      ns.sub-nosig    A       10.10.10.4

   A query to generated directly via some
      form of application interface which instructed the authoritative name server security-aware
      resolver not to perform validation for this zone for
   QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce:

      Flags:  QR=1, AA=1, RCODE=0 (NOERROR)
      EDNS:   DO=1, size=4000
      QUERY:
         c.example.com.         IN A
      ANSWER:
         c.example.com.         IN A   a.example.com
                                IN RRSIG CNAME
         a.example.com.         IN A   10.10.10.1
                                IN RRSIG A
      AUTHORITY:
         example.com.           IN NS  a.example.com.
                                IN NS  b.example.com.
                                IN RRSIG NS ...
      ADDITIONAL:
         a.example.com.         IN A   10.10.10.1
                                IN RRSIG query; or

   o  Validation for this query has been disabled by local policy.

   A ...
         b.example.com.         IN security-aware resolver's support for signature verification MUST
   include support for verification of wildcard owner names.

   A   10.10.10.2
                                IN security-aware resolver MUST attempt to retrieve missing DS,
   DNSKEY, or RRSIG A ...

   A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
   results RRs via explicit queries if the resolver needs these
   RRs in a referral order to perform signature verification.

   A security-aware resolver MUST attempt to retrieve a signed zone.  The missing NSEC RR
   which the resolver can determine
   that "sub.example.com" needs to authenticate a NODATA response.  In
   general it is signed because of not possible for a resolver to retrieve missing NSEC
   RRs, since the presence resolver will have no way of knowing the DS RR
   with the hash owner name of
   the "sub.example.com" zone key.

      Flags:  QR=1, AA=1, RCODE=0 (NOERROR)
      EDNS:   DO=1, size=4000
      QUERY:
         www.sub.example.com.  IN   A
      ANSWER:
         ;; empty
      AUTHORITY:
         sub.example.com.      IN  NS  ns.sub.example.com.
                               IN  DS  ...

                               IN  RRSIG DS ...
      ADDITIONAL:
         ns.sub.example.com.   IN  A   10.10.10.3

   A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A
   would result missing NSEC RR, but in the specific case of a referral to an unsigned zone. The NODATA response,
   the resolver knows
   not does know the name of the missing NSEC RR, and must
   therefore attempt to expect DNSSEC retrieve it.

   When attempting to retrieve missing NSEC or DS RRs from "sub-nosig.example.com", because which reside on
   the DS
   bit in parental side at a zone cut, a security-aware iterative-mode
   resolver MUST query the NSEC RR bitmap in name servers for the referral is parent zone, not set.  Even if DNSSEC
   RRs are present in responses from "sub-nosig.example.com" name
   servers, the
   child zone.

   A security-aware resolver will not MUST be able to construct determine whether or not it
   should expect a authentication
   chain, since there particular RRset to be signed.  More precisely, a
   security-aware resolver must be able to distinguish between three
   cases:

   1.  An RRset for which the resolver is able to build a break between "sub-nosig.example.com" chain of
       signed DNSKEY and its
   delegating parent zone.

      Flags:  QR=1, AA=1, RCODE=0 (NOERROR)
      EDNS:   DO=1, size=4000
      QUERY:
         www.sub-nosig.example.com.  IN  A
      ANSWER:
         ;; empty
      AUTHORITY:
         sub-nosig.example.com.      IN  NS  ns.sub-nosig.example.com.
                                     IN  NSEC ;; (DS bit not set)
                                     IN  RRSIG NSEC ...
      ADDITIONAL:
         ns.sub-nosig.example.com.   IN  A   10.10.10.4

   A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns DS RRs from a name
   error, because the name does not exist and is not covered by wildcard
   expansion.  Therefore, trusted starting point to the name server must present proof that
       RRset.  In this case, the
   name does not exist, RRset should be signed, and that no wildcard expansion is present which
   could have been used subject
       to answer the query.

      Flags:  QR=1, AA=1, RCODE=3 (NXDOMAIN)
      EDNS:   DO=1, size=4000
      QUERY:
         f.example.com.        IN  A
      ANSWER:
         ;; empty
      AUTHORITY:
         example.com.          IN  SOA ...
                               IN  RRSIG SOA ...
         c.example.com.        IN  NSEC sub.example.com. ...
                               IN  RRSIG NSEC ...
         *.example.com.        IN  NSEC a.example.com. ...
                               IN  RRSIG NSEC ...
      ADDITIONAL:
         example.com.          IN  DNSKEY ...
                               IN  RRSIG DNSKEY ...

   A query signature validation as described above.

   2.  An RRset for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
   RR synthesized via wildcard expansion.  The name server must prove which the resolver knows that it has no exact match exists.

      Flags:  QR=1, AA=1, RCODE=0 (NOERROR)
      EDNS:   DO=1, size=4000
      QUERY:
         f.example.com.        IN  MX
      ANSWER:
         f.example.com.        IN  MX  10 a.example.com.
                               IN  RRSIG MX ...
      AUTHORITY:
         example.com.          IN  NS  a.example.com.
                               IN  NS  b.example.com.
                               IN  RRSIG NS ...
         c.example.com.        IN  NSEC sub.example.com.
                               IN  RRSIG NSEC ...
      ADDITIONAL:
         a.example.com.        IN  A   10.10.10.1
                               IN  RRSIG A ...
         b.example.com.        IN  A   10.10.10.2
                               IN  RRSIG A ...

   If these responses came from a recursive name server which had all chain of
       signed DNSKEY and DS RRs from any trusted starting point to the necessary RRsets
       RRset.  This can occur when the target RRset lies in its cache instead an unsigned
       zone or in a descendent of from an authoritative
   server, unsigned zone.  In this case, the only differences would
       RRset may or may not be signed, but the TTLs and the header flags.
   The AA bit would resolver will not be set, and able
       to verify the signature.

   3.  An RRset for which the resolver is not able to determine whether
       or not the AD bit would RRset should be set if (and only
   if) all the RRsets in a response passed signed, because the security policy checks of resolver is not
       able to obtain the recursive name server.

4. Resolving necessary DNSSEC RRs. This section describes can occur when the behavior of entities which 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 is not able to contact security-aware recursive
       name servers are described in a
   separate subsection.

   A security-aware resolver MUST include an EDNS [RFC2671] OPT
   pseudo-RR with for the DO [RFC3225] bit set to one when sending queries. relevant zones.

   A security-aware resolver MUST support a message size be capable of being preconfigured with
   at least
   1220 octets, SHOULD support a message size of 4000 octets, one trusted public key, and MUST
   advertise the supported message size using the "sender's UDP payload
   size" field in the EDNS OPT pseudo-RR. A be capable of being
   preconfigured with multiple trusted public keys or DS RRs. Since a
   security-aware resolver MUST
   handle fragmented UDP packets correctly regardless of whether any will not be able to validate signatures
   without such fragmented packets were received via IPv4 or IPv6.  Please see
   [RFC3226] a preconfigured trusted key, the resolver SHOULD have
   some reasonably robust mechanism for discussion of these requirements. obtaining such keys when it
   boots.

   A security-aware resolver MUST support the signature verification
   mechanisms described in Section 5, and MUST apply them to every
   received SHOULD cache each response except when:

   o as a single
   atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
   single atomic entry containing the entire answer, including the named
   RRset and any associated DNSSEC RRs. The security-aware resolver is part of a security-aware recursive
      name server, and the response is SHOULD discard the result of recursion on behalf
   entire atomic entry when any of a query received with the RRs contained in it expire.

   A security-aware resolver MAY set the CD bit set;

   o  The response is the result of in a query generated directly via some
      form of application interface which instructed to one in
   order to indicate that the security-aware resolver not to perform validation takes responsibility for this query; or

   o  Validation
   performing whatever authentication its local policy requires on the
   RRsets in the response.  See Section 3.2 for the effect this query bit has been disabled by local policy.

   A security-aware resolver's support for signature verification MUST
   include support for verification
   on the behavior of wildcard owner names. security-aware recursive name servers.

   A security-aware resolver MUST attempt to retrieve missing DS,
   DNSKEY, or RRSIG RRs via explicit queries if zero the resolver needs these
   RRs in order to perform signature verification. AD bit when composing query
   messages.

4.1 Rate Limiting

   A security-aware resolver MUST attempt to retrieve missing a NSEC RR
   which the resolver needs to authenticate a NODATA response.  In
   general it is not possible for SHOULD NOT cache data with invalid
   signatures under normal circumstances.  However, a security-aware
   resolver SHOULD take steps to retrieve missing NSEC
   RRs, since rate limit the resolver will have no way number of knowing the owner name identical
   queries that it generates if signature validation of the missing NSEC RR, but responses
   fails repeatedly.

   Conceptually, this is similar in the specific case of a NODATA response, some respects to negative caching
   [RFC2308], but since the resolver does know the name has no way of obtaining an
   appropriate caching TTL from received data in this case, the missing NSEC RR, and must
   therefore attempt TTL will
   have to retrieve it.

   A security-aware resolver MUST be able to determine whether or not it
   should expect a particular RRset set by the implementation.  This document refers to be signed.  More precisely, the
   data retained as part of such a rate limiting mechanism as the "BAD
   cache".

   A security-aware resolver must be able MAY chose to distinguish between three
   cases:

   1.  An RRset retain RRsets for which
   signature validation has failed in its BAD cache, but MUST NOT return
   such RRsets from its BAD cache unless both of the following
   conditions are met:

   o  The resolver is able to build a chain of
       signed DNSKEY and DS RRs from a trusted starting point has recently generated enough queries identical to the
       RRset.  In
      this case, one that the RRset should be signed, and resolver is subject
       to signature validation as described above.

   2.  An RRset suppressing queries for which the resolver knows that it has no chain of
       signed DNSKEY this <QNAME,
      QTYPE, QCLASS>; and DS RRs from any trusted starting point

   o  The resolver is not required to validate the
       RRset.  This can occur when signatures of the target RRset lies
      RRsets in an unsigned
       zone or question under the rules given in a descendent Section 4 of an unsigned zone.  In this case, the
       RRset may or may not be signed, but
      document.

   The intent of the resolver will not be able above rule is to verify provide the signature.

   3.  An RRset for raw data to clients
   which are capable of performing their own signature verification
   checks while protecting clients which depend on this resolver to
   perform such checks.  Several of the resolver is possible reasons why signature
   validation might fail involve conditions which may not able apply equally
   to determine whether
       or not this resolver and the RRset should client which invoked it: for example, this
   resolver's clock may be signed, because set incorrectly, or the client may have
   knowledge of a relevant island of security which this resolver is does
   not
       able to obtain share.  In such cases, "protecting" a client which is capable of
   performing its own signature validation from ever seeing the necessary DNSSEC RRs. This can occur when "bad"
   data does not help the client.

4.2 Stub resolvers

   A security-aware stub resolver is not able to contact security-aware
       name servers for MUST include an EDNS [RFC2671] OPT
   pseudo-RR with the relevant zones. DO [RFC3225] bit set to one when sending queries.

   A security-aware stub resolver MUST be capable support a message size of being preconfigured with at
   least one trusted public key, 1220 octets, SHOULD support a message size of 4000 octets, and
   MUST be capable of being
   preconfigured with multiple trusted public keys or DS RRs. Since a advertise the supported message size using the "sender's UDP
   payload size" field in the EDNS OPT pseudo-RR. A security-aware stub
   resolver will not be able to validate signatures
   without MUST handle fragmented UDP packets correctly regardless of
   whether any such a preconfigured trusted key, the resolver SHOULD have
   some reasonably robust mechanism fragmented packets were received via IPv4 or IPv6.
   Please see [RFC3226] for obtaining such keys when it
   boots. discussion of these requirements.

   A security-aware stub resolver SHOULD cache each response as a single
   atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
   single atomic entry containing MUST support the entire answer, including DNSSEC RR types, at
   least to the named
   RRset and any associated extent of not mishandling responses just because they
   contain DNSSEC RRs. The   A security-aware stub resolver SHOULD discard MAY include the
   entire atomic entry when any
   DNSSEC RRs returned by a security-aware recursive name server as part
   of the RRs contained in data that it expire. the stub resolver hands back to the application
   which invoked it but is not required to do so.

   A security-aware stub resolver SHOULD NOT cache data with invalid
   signatures under normal circumstances.  However, set the CD bit when sending
   queries, since, by definition, a security-aware stub resolver SHOULD take steps to rate limit the number of identical
   queries it generates, which may require does
   not validate signatures and thus depends on the resolver security-aware
   recursive name server to retain some
   data about recently generated queries. Conceptually, this is similar perform validation on its behalf.

   A security-aware stub resolver MAY chose to negative caching [RFC2308], but since examine the resolver has no way setting of
   obtaining
   the appropriate caching TTL from received data AD bit in this
   case, the TTL will have response messages that it receives in order to be set by the implementation.  This
   document refers data retained as part of such a rate limiting
   mechanism as
   determine whether the "BAD cache".

4.1 Recursive Name Servers

   As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware recursive name server is an entity which acts sent
   the response claims to have cryptographically verified the data in both
   the
   security-aware name server Answer and security-aware resolver roles. This
   section uses Authority sections of the terms "name server side" and "resolver side" to
   refer to response message.  Note,
   however, that the code within responses received by a security-aware recursive name server which
   implements the security-aware name server role and stub
   resolver are heavily dependent on the code which
   implements local policy of the
   security-aware resolver role, respectively.

   A security-aware recursive name server MUST NOT attempt server, so as a practical matter there
   may be little practical value to answer checking the status of the AD bit
   except perhaps as a
   query by piecing together cached 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 it received in response to
   previous queries that requested different QNAMEs, QTYPEs, or
   QCLASSes.  A question from a trusted security-aware
   recursive name server MUST NOT via a secure channel.

5. Authenticating DNS Responses

   In order to use NSEC DNSSEC RRs from one negative response to synthesize a response for authentication, a
   different query.  A security-aware recursive name server MUST NOT use
   resolver requires preconfigured knowledge of at least one
   authenticated DNSKEY or DS RR.  The process for obtaining and
   authenticating this initial DNSKEY or DS RR is achieved via some
   external mechanism.  For example, a previous wildcard expansion resolver could use some off-line
   authenticated exchange to generate obtain a response to zone's DNSKEY RR or obtain a different
   query. DS RR
   that identifies and authenticates a zone's DNSKEY RR.  The name server side remainder
   of a security-aware recursive name server MUST
   pass this section assumes that the sense resolver has somehow obtained an
   initial set of authenticated DNSKEY RRs.

   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
   RRset.  To authenticate an apex DNSKEY RRset using an initial key,
   the resolver MUST:

   1.  Verify that the initial DNSKEY RR appears in the apex DNSKEY
       RRset, and verify that the DNSKEY RR has the CD Zone Key Flag
       (DNSKEY RDATA bit 7) set to the resolver side along with the rest
   of an initiating query, so one.

   2.  Verify that the resolver side will know whether
   whether or not it there is required to verify some RRSIG RR which covers the response data it returns
   to apex DNSKEY
       RRset, and that the name server side.

   The resolver side combination of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of RRSIG RR and the state of initial
       DNSKEY RR authenticates the DO
   bit DNSKEY RRset.  The process for using
       an RRSIG RR to authenticate an RRset is described in Section 5.3.

   Once the initiating request received by the name server side.  If resolver has authenticated the DO bit in apex DNSKEY RRset using an initiating query is not set, the name server side
   MUST strip any authenticating DNSSEC RRs
   initial DNSKEY RR, delegations from the response, but but
   MUST NOT strip any DNSSEC RRs that the initiating query explicitly
   requested.

   The zone can be authenticated
   using DS RRs.  This allows a resolver side MUST follow the usual rules for caching to start from an initial key,
   and
   negative caching which would apply use DS RRsets to any security-aware resolver. proceed recursively down the DNS tree obtaining
   other apex DNSKEY RRsets.  If the name server side receives resolver were preconfigured with a query which matches an entry in
   root DNSKEY RR, and if every delegation had a DS RR associated with
   it, then the resolver side's BAD cache, the name server side's response
   depends on could obtain and validate any apex DNSKEY
   RRset.  The process of using DS RRs to authenticate referrals is
   described in Section 5.2.

   Once the setting of resolver has authenticated a zone's apex DNSKEY RRset,
   Section 5.3 shows how the CD bit resolver can use DNSKEY RRs in the original query.  If apex
   DNSKEY RRset and RRSIG RRs from the
   CD bit is set, zone to authenticate any other
   RRsets in the name server side SHOULD return zone.  Section 5.4 shows how the data resolver can use
   authenticated NSEC RRsets from the
   BAD cache; if the CD bit zone to prove that an RRset is not set,
   present in the name server side SHOULD
   return RCODE 2 (server failure).

   The name server side of zone.

   When a security-aware recursive name server MUST
   NOT set the AD bit in resolver indicates support for DNSSEC, a response unless the security-aware name
   server considers all
   RRsets in the Answer or Authority sections of the response should attempt to be
   authentic, and SHOULD set provide the AD bit if necessary DNSKEY, RRSIG, NSEC,
   and only if the name server
   considers all DS RRsets in the Answer section and any relevant negative a response RRs in the Authority section to be authentic.  How the name
   server side of (see Section 3).  However, a
   security-aware recursive name server determines
   whether an RRset is authentic depends on the origin of the RRset.  If
   the RRset came from the resolver side of may still receive a response which that lacks
   the appropriate DNSSEC RRs, whether due to configuration issues such
   as a security-oblivious recursive name server
   (the normal case), recursive name server MUST follow the procedure
   described which accidentally
   interfere with DNSSEC RRs or due to a deliberate attack in Section 5.  If the RRset came which an
   adversary forges a response, strips DNSSEC RRs from a zone for which the
   name server side of the recursive name server is authoritative, local
   policy MAY consider the RRset response, or
   modifies a query so that DNSSEC RRs appear not to be authentic without further
   verification simply because the RRset came from an authoritative
   zone, but the name server SHOULD NOT do so unless the it obtained the
   authoritative zone via secure means (such as requested.  The
   absence of DNSSEC data in a secure zone transfer
   mechanism), and response MUST NOT do so unless this behavior has been
   configured explicitly.

4.2 Stub resolvers by itself be taken as
   an indication that no authentication information exists.

   A security-aware stub resolver MUST include an EDNS [RFC2671] OPT
   pseudo-RR with the DO [RFC3225] bit set to one when sending queries. SHOULD expect authentication information from signed
   zones. A security-aware stub resolver MUST support a message size of at
   least 1220 octets, SHOULD support believe that a message size of 4000 octets, and
   MUST advertise zone is signed if the supported message size using
   resolver has been configured with public key information for the "sender's UDP
   payload size" field in
   zone, or if the EDNS OPT pseudo-RR. A security-aware stub
   resolver MUST handle fragmented UDP packets correctly regardless zone's parent is signed and the delegation from the
   parent contains a DS RRset.

5.1 Special Considerations for Islands of
   whether any such fragmented packets were received via IPv4 or IPv6.
   Please see [RFC3226] Security

   Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
   zones for discussion which it is not possible to construct an authentication
   chain to the zone from its parent.  Validating signatures within an
   island of security requires the validator to have some other means of these requirements.

   A security-aware stub resolver MUST support
   obtaining an initial authenticated zone key for the DNSSEC RR types, at
   least island.  If a
   validator cannot obtain such a key, it will have to choose whether to
   accept the extent of unvalidated responses or not mishandling based on local policy.

   All the normal processes for validating responses just because they
   contain DNSSEC RRs.   A security-aware stub resolver MAY include apply to islands of
   security.  The only difference between normal validation and
   validation within an island of security is in how the
   DNSSEC RRs returned by validator
   obtains a security-aware recursive name server as part
   of starting point for the data that it authentication chain.

5.2 Authenticating Referrals

   Once the stub resolver hands back apex DNSKEY RRset for a signed parent zone has been
   authenticated, DS RRsets can be used to authenticate the application
   which invoked it but is not required delegation
   to do so. a signed child zone.  A security-aware stub resolver SHOULD NOT set DS RR identifies a DNSKEY RR in the CD bit when sending
   queries, since, by definition, child
   zone's apex DNSKEY RRset, and contains a security-aware stub resolver does cryptographic digest of the
   child zone's DNSKEY RR.  A strong cryptographic digest algorithm
   ensures that an adversary can not validate signatures and thus depends on easily generate a DNSKEY RR that
   matches the security-aware
   recursive name server digest.  Thus, authenticating the digest allows a
   resolver to perform validation on its behalf.

   A security-aware stub authenticate the matching DNSKEY RR.  The resolver MAY chose can
   then use this child DNSKEY RR to examine authenticate the entire child apex
   DNSKEY RRset.

   Given a DS RR for a delegation, the setting child zone's apex DNSKEY RRset
   can be authenticated if all of the AD bit following hold:

   o  The DS RR has been authenticated using some DNSKEY RR in response messages that it receives the
      parent's apex DNSKEY RRset (see Section 5.3);

   o  The Algorithm and Key Tag in order to
   determine whether the security-aware recursive name server which sent DS RR match the response claims to have cryptographically verified Algorithm field
      and the data key tag of a DNSKEY RR in the Answer and Authority sections of child zone's apex DNSKEY
      RRset which, when hashed using the response message.  Note,
   however, that digest algorithm specified in
      the responses received by DS RR's Digest Type field, results in a security-aware stub
   resolver are heavily dependent on digest value which
      matches the local policy Digest field of the
   security-aware recursive name server, so as a practical matter there
   may be little practical value to checking DS RR; and

   o  The matching DNSKEY RR in the status of child zone has the AD Zone Flag 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 set
      to one, the security-aware stub
   resolver obtained corresponding private key has signed the data in question 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 trusted security-aware
   recursive name server via a secure channel.

5. Authenticating DNS Responses

   In order to use DNSSEC RRs for authentication, 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 requires preconfigured knowledge of at least one
   authenticated DNSKEY or DS RR.  The process MUST query the name servers for obtaining and
   authenticating this initial DNSKEY or the parent
   zone for the DS RR 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 obtain RRset if the referral includes neither a DS RR RRset nor
   a NSEC RRset proving that identifies and the DS RRset does not exist (see Section
   4).

   If the resolver authenticates a zone's DNSKEY RR.  The remainder
   of this section assumes an NSEC RRset which 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 somehow obtained an initial set of authenticated
   DNSKEY RRs.

   An or DS RR which belongs to the child zone or to any delegation
   below the child zone, this initial DNSKEY or DS RR can MAY be used to authenticate a zone's apex DNSKEY
   RRset.  To authenticate an apex DNSKEY RRset using
   re-establish an authentication path.  If no such initial key, DNSKEY or DS
   RR exists, the resolver MUST:

   1.  Verify that can not authenticate RRsets in or below the initial DNSKEY
   child zone.

   Note that, for a signed delegation, there are two NSEC RRs associated
   with the delegated name.  One NSEC RR appears resides in the apex DNSKEY
       RRset, parent zone, and verify that
   can be used to prove whether a DS RRset exists for the DNSKEY delegated
   name.  The second NSEC RR has resides in the Zone Key Flag
       (DNSKEY RDATA bit 7) set to one.

   2.  Verify that there is some RRSIG RR child zone, and identifies
   which covers RRsets are present at the apex DNSKEY
       RRset, and that the combination of the RRSIG child zone.  The parent
   NSEC RR and the initial
       DNSKEY child NSEC RR authenticates can always be distinguished, since the DNSKEY RRset.  The process for using
       an RRSIG SOA
   bit will be set in the child NSEC RR to authenticate an RRset is described and clear in Section 5.3.

   Once the parent NSEC RR.
   A security-aware resolver has authenticated MUST use the apex DNSKEY RRset using an
   initial DNSKEY RR, delegations from parent NSEC RR when attempting
   to prove that zone can be authenticated
   using DS RRs.  This allows a DS RRset does not exist.

5.3 Authenticating an RRset Using an RRSIG RR

   A resolver to start from can use an initial key, RRSIG RR and use DS RRsets to proceed recursively down the DNS tree obtaining
   other apex its corresponding DNSKEY RR to
   attempt to authenticate RRsets.  If the  The resolver were preconfigured with a
   root DNSKEY RR, and if every delegation had a DS first checks the RRSIG
   RR associated with
   it, then to verify that it covers the resolver could obtain RRset, has a valid time interval, and validate any apex
   identifies a valid DNSKEY
   RRset. RR.  The process resolver then constructs the
   canonical form of using DS RRs to authenticate referrals is
   described in Section 5.2.

   Once the resolver has authenticated a zone's apex DNSKEY RRset,
   Section 5.3 shows how signed data by appending the RRSIG RDATA
   (excluding the Signature Field) with the canonical form of the
   covered RRset.  Finally, resolver can use DNSKEY RRs in uses the apex
   DNSKEY RRset public key and RRSIG RRs from the zone signature
   to authenticate any other
   RRsets in the zone. signed data.  Section 5.4 shows how 5.3.1, Section 5.3.2, and
   Section 5.3.3 describe each step in detail.

5.3.1 Checking the RRSIG RR Validity

   A security-aware resolver can use
   authenticated NSEC RRsets from the zone an RRSIG RR to prove that authenticate an
   RRset is not
   present in if all of the zone.

   When a resolver indicates support for DNSSEC, a security-aware name
   server should attempt to provide following conditions hold:

   o  The RRSIG RR and the necessary DNSKEY, RRSIG, NSEC, RRset MUST have the same owner name and DS RRsets in a response (see Section 3).  However, a
   security-aware resolver may still receive a response which that lacks the appropriate DNSSEC RRs, whether due to configuration issues such
   as a security-oblivious recursive
      same class;

   o  The RRSIG RR's Signer's Name field MUST be the name server which accidentally
   interfere 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 of the zone
      that DNSSEC RRs appear not to be requested. contains the RRset;

   o  The
   absence RRSIG RR's Type Covered field MUST equal the RRset's type;

   o  The number of DNSSEC data labels in a response the RRset owner name 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, greater than
      or if the zone's parent is signed and equal to the delegation from value in the
   parent contains a DS RRset.

5.1 Special Considerations for Islands of Security

   Islands RRSIG RR's Labels field;

   o  The resolver's notion of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
   zones for which it is not possible to construct an authentication
   chain the current time MUST be less than or
      equal to the zone from its parent.  Validating signatures within an
   island of security requires time listed in the validator to have some other means RRSIG RR's Expiration field;

   o  The resolver's notion of
   obtaining a trusted zone key.  If a validator cannot obtain such a
   key, it will have to choose whether to accept the unvalidated
   responses current time MUST be greater than or not based on local policy.

   All the normal processes for validating responses apply
      equal to islands of
   security. the time listed in the RRSIG RR's Inception field;

   o  The only difference between normal validation RRSIG RR's Signer's Name, Algorithm, and
   validation within an island of security is in how Key Tag fields MUST
      match the validator
   obtains a trusted starting point owner name, algorithm, and key tag for some DNSKEY RR in
      the authentication chain.

5.2 Authenticating Referrals

   Once the zone's 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 RRset;

   o  The matching DNSKEY RR MUST be present in the child zone's apex DNSKEY
      RRset, and contains a cryptographic digest of the
   child zone's DNSKEY RR.  A strong cryptographic digest algorithm
   ensures that an adversary can not easily generate a MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
      set to one.

   It is possible for more than one DNSKEY RR that
   matches to match the digest.  Thus, authenticating conditions
   above.  In this case, the digest allows a resolver can not predetermine which DNSKEY
   RR to use to authenticate the signature, MUST try each matching
   DNSKEY RR.  The RR until the resolver can
   then use has either validated the signature or
   has run out of matching keys to try.

   Note that this child authentication process is only meaningful if the
   resolver authenticates the DNSKEY RR before using it to authenticate the entire child apex validate
   signatures.  The matching DNSKEY RRset.

   Given a DS RR for a delegation, the child zone's is considered to be authentic if:

   o  The apex DNSKEY RRset
   can be authenticated if all of containing the following hold: DNSKEY RR is considered
      authentic; or

   o  The DS RR has been authenticated using some DNSKEY RRset covered by the RRSIG RR in is the
      parent's apex DNSKEY RRset (see Section 5.3);

   o  The Algorithm itself,
      and Key Tag in the DNSKEY RR either matches an authenticated DS RR match the Algorithm field
      and from the key tag of
      parent zone or matches a DNSKEY DS RR in the child zone's apex or DNSKEY
      RRset which, when hashed using the digest algorithm specified in
      the DS RR's Digest Type field, results in a digest value RR which
      matches the Digest field of resolver has
      been preconfigured to believe to be authentic.

5.3.2 Reconstructing the DS RR; and

   o  The matching DNSKEY RR in Signed Data

   Once the child zone RRSIG RR has met the Zone Flag bit set validity requirements described in
   Section 5.3.1, the resolver needs to one, reconstruct the corresponding private key has original signed
   data.  The original signed data includes RRSIG RDATA (excluding the child zone's
      apex DNSKEY RRset,
   Signature field) and the resulting RRSIG RR authenticates canonical form of the
      child zone's apex DNSKEY RRset.

   If the referral  Aside from
   being ordered, the parent zone did not contain a DS RRset, canonical form of the
   response should have included a signed NSEC RRset proving that no DS RRset exists for might also differ from
   the delegated received RRset due to DNS name (see Section 3.4).  A
   security-aware compression, decremented TTLs, or
   wildcard expansion.  The resolver MUST query should use the name servers for following to
   reconstruct the parent
   zone for original signed data:

         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where

            "|" denotes concatenation

            RRSIG_RDATA is the DS RRset if wire format of the referral includes neither a DS RRset nor
   a NSEC RRset proving that RRSIG RDATA fields
               with the DS RRset does not exist (see Section
   4).

   If Signature field excluded and the resolver authenticates an NSEC RRset which proves that no DS
   RRset Signer's Name
               in canonical form.

            RR(i) = name | class | type | OrigTTL | RDATA length | RDATA

               name is present for this zone, then there calculated according to the function below

               class is no authentication path
   leading the RRset's class

               type is the RRset type and all RRs in the class

               OrigTTL is the value from the parent to RRSIG Original TTL field

               All names in the RDATA field are in canonical form

               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 = RRset's fully qualified domain name in
                               canonical form

               if rrsig_labels = fqdn_labels,
                   name = fqdn

               if rrsig_labels < fqdn_labels,
                  name = "*." | the leftmost rrsig_label labels of the child.  If
                                fqdn
               if rrsig_labels > fqdn
                  the resolver has an initial
   DNSKEY or DS RRSIG RR which belongs to the child zone or to any delegation
   below did not pass the child zone, this initial DNSKEY or DS RR MAY necessary validation
                  checks and MUST NOT be used to
   re-establish an authentication path.  If no such initial DNSKEY or DS
   RR exists, the resolver can not authenticate this
                  RRset.

   The canonical forms for names and RRsets are defined in or below the
   child zone.

   Note that, for
   [I-D.ietf-dnsext-dnssec-records].

   NSEC RRsets at a signed delegation, there delegation boundary require special processing.
   There are two distinct NSEC RRs RRsets associated with the a signed delegated
   name.  One NSEC RR RRset resides in the parent zone, and
   can be used to prove whether a DS specifies which
   RRset exists for are present at the delegated
   name. parent zone.  The second NSEC RR RRset resides in
   at the child zone, and identifies which RRsets are present at the
   apex of in the child zone.  The parent NSEC RR RRset and child NSEC RR RRset
   can always be distinguished, distinguished since the SOA
   bit will be set in only 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.

5.3 Authenticating an RRset Using an RRSIG RR

   A resolver can use RRs will
   specify an RRSIG RR and its corresponding DNSKEY RR to
   attempt to authenticate RRsets.  The resolver first checks the RRSIG
   RR to verify that it covers the RRset, has a valid time interval, and
   identifies a valid DNSKEY RR.  The resolver then constructs SOA RRset exists at the
   canonical form of name. When reconstructing the signed data by appending
   original NSEC RRset for the RRSIG RDATA
   (excluding delegation from the Signature Field) parent zone, the NSEC
   RRs MUST NOT be combined with NSEC RRs from the canonical form child zone, and when
   reconstructing the original NSEC RRset for the apex of the
   covered RRset.  Finally, resolver uses child
   zone, the public key and signature
   to authenticate NSEC RRs MUST NOT be combined with NSEC RRs from the signed data.  Section 5.3.1, Section 5.3.2, and
   Section 5.3.3 describe parent
   zone.

   Note also that 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 two NSEC RRsets at a delegation point has
   a corresponding RRSIG RR and the RRset MUST have the same with an owner name matching the delegated
   name, and each of these RRSIG RRs is authoritative data associated
   with the same class;

   o  The zone which contains the corresponding NSEC RRset.  If
   necessary, a resolver can tell these RRSIG RR's RRs apart by checking the
   Signer's Name field MUST be field.

5.3.3 Checking the name of Signature

   Once the zone
      that contains resolver has validated the RRset;

   o  The RRSIG RR's Type Covered field MUST equal the RRset's type;

   o  The number of labels RR as described in Section
   5.3.1 and reconstructed the RRset owner name MUST be greater than
      or equal to the value original signed data as described in
   Section 5.3.2, the RRSIG RR's Labels field;

   o  The resolver's notion of resolver can attempt to use the current time MUST be less than or
      equal cryptographic
   signature to authenticate the time listed signed data, and thus (finally!)
   authenticate the RRset.

   The Algorithm field in the RRSIG RR's Expiration field;

   o  The resolver's notion of RR identifies the current time MUST be greater than or
      equal cryptographic
   algorithm to generate the time listed signature.  The signature itself is
   contained in the Signature field of the RRSIG RR's Inception field;

   o  The RRSIG RR's Signer's Name, Algorithm, RDATA, and Key Tag fields MUST
      match the owner name, algorithm, and public
   key tag for some DNSKEY RR to used generate the signature is contained in the zone's apex DNSKEY RRset;

   o  The Public Key
   field of the matching DNSKEY RR MUST be present RR(s) (found in the zone's apex DNSKEY
      RRset, Section 5.3.1).
   [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
   and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
      set provides pointers to one.

   It the documents that define each algorithm's
   use.

   Note that it is possible for more than one DNSKEY RR to match the
   conditions
   above. in Section 5.3.1.  In this case, the resolver can not predetermine only
   determine which DNSKEY RR by trying each matching key until the
   resolver 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 RRSIG RR, the local resolver
   security policy determines whether the resolver also needs to test
   these RRSIG RRs, and determines how to use resolve conflicts if these
   RRSIG RRs lead to authenticate the signature, MUST try each matching
   DNSKEY RR until differing results.

   If the resolver has either validated accepts the signature or
   has run out of matching keys to try.

   Note that this authentication process is only meaningful if RRset as authentic, the resolver authenticates MUST set
   the DNSKEY TTL of the RRSIG RR before using it to validate
   signatures.  The matching DNSKEY and each RR is considered in the authenticated RRset to be authentic if: a
   value no greater than the minimum of:

   o  The apex DNSKEY RRset containing RRset's TTL as received in the DNSKEY RR is considered
      authentic; or response;

   o  The RRset covered by the RRSIG RR is RR's TTL as received in the apex DNSKEY RRset itself, response; and

   o  The value in the DNSKEY RR either matches an authenticated DS RR from RRSIG RR's Original TTL field.

5.3.4 Authenticating A Wildcard Expanded RRset Positive Response

   If the
      parent zone or matches a DS RR or DNSKEY RR which number of labels in an RRset's fully qualified domain name is
   greater than the resolver has
      been preconfigured to believe to be authentic.

5.3.2 Reconstructing Labels field in the Signed Data

   Once covering RRSIG RDATA, then the
   RRset and its covering RRSIG RR were created as a result of wildcard
   expansion.  Once the resolver has met verified the validity requirements signature as described
   in Section 5.3.1, 5.3, the resolver needs must take additional steps 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, verify the canonical form
   non-existence of an exact match or closer wildcard match for the RRset might also differ from
   query.   Section 5.4 discusses these steps.

   Note that the response received RRset due to DNS name compression, decremented TTLs, or
   wildcard expansion.  The by the resolver should use the following include all
   NSEC RRs needed to
   reconstruct the original signed data:

         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where

            "|" denotes concatenation

            RRSIG_RDATA is authenticate the wire format response (see Section 3.1.3).

5.4 Authenticated Denial of the RRSIG RDATA fields
               with the Signature field excluded and the Signer's Name Existence

   A resolver can use authenticated NSEC RRs to prove that an RRset is
   not present in canonical form.

            RR(i) = name | class | type | OrigTTL | RDATA length | RDATA a signed zone.  Security-aware name is calculated servers should
   automatically include any necessary NSEC RRs for signed zones in
   their responses to security-aware resolvers.

   Security-aware resolvers MUST first authenticate NSEC RRsets
   according to the function below

               class is the RRset's class

               type is the standard RRset type and all RRs authentication rules described in
   Section 5.3, then apply the class

               OrigTTL is NSEC RRsets as follows:

   o  If the value from requested RR name matches the RRSIG Original TTL field

               All names in owner name of an
      authenticated NSEC RR, then the RDATA NSEC RR's type bit map field are in canonical form

               The set of lists
      all RR(i) is sorted into canonical order.

            To calculate the name:
               let rrsig_labels = the value of RR types present at that owner name, and a resolver can prove
      that the RRSIG Labels field

               let fqdn = RRset's fully qualified domain name in
                               canonical form

               let fqdn_labels = RRset's fully qualified domain name requested RR type does not exist by checking for the RR
      type in
                               canonical form

               if rrsig_labels = fqdn_labels,
                   name = fqdn

               if rrsig_labels < fqdn_labels,
                  name = "*." | the leftmost rrsig_label labels of bit map.  Since the
                                fqdn
               if rrsig_labels > fqdn existence of the RRSIG authenticated
      NSEC RR did not pass proves that the necessary validation
                  checks and MUST NOT be owner name exists in the zone, wildcard
      expansion could not have been used to authenticate this
                  RRset.

   Section 5.5.1 gives match the requested RR owner
      name and type.

   o  If the requested RR name would appear after an example of original authenticated NSEC
      RR owner name calculation.  The
   canonical forms for names and RRsets are defined before the name listed in
   [I-D.ietf-dnsext-dnssec-records].

   NSEC RRsets at a delegation boundary require special processing.
   There are two distinct NSEC RRsets associated with a signed delegated
   name.  One that NSEC RRset resides RR's Next
      Domain Name field according to the canonical DNS name order
      defined in [I-D.ietf-dnsext-dnssec-records], then no exact match
      for the parent zone, and specifies which
   RRset are present at requested RR name exists in the parent zone.  The second NSEC RRset resides
   at However, it is
      possible that a wildcard could be used to match the child zone, requested RR
      owner name and identifies type, so proving that the requested RRset does not
      exist also requires proving that no possible wildcard exists which RRsets are present at
      could have been used to generate a positive response.

   To prove non-existence of an RRset, the
   apex in resolver must be able to
   verify both that the child zone.  The parent NSEC queried RRset does not exist and child NSEC that no
   relevant wildcard RRset
   can always be distinguished since only the child exists.  Proving this may require more than
   one NSEC RRs will
   specify an SOA RRset exists at from the name. When reconstructing zone.  If the
   original complete set of necessary NSEC RRset for the delegation from
   RRsets is not present in a response (perhaps due to truncation), then
   a security-aware resolver MUST resend the parent zone, query in order to attempt
   to obtain the full collection of NSEC RRs MUST NOT be combined necessary to verify
   non-existence of the requested RRset.   As with NSEC RRs from all DNS operations,
   however, the child zone, and when
   reconstructing resolver MUST bound the original work it puts into answering any
   particular query.

   Since a verified NSEC RRset for RR proves the apex existence of the child
   zone, the NSEC RRs both itself and its
   corresponding RRSIG RR, a verifier MUST NOT be combined with NSEC RRs from ignore the parent
   zone.

   Note also that each settings of the two
   NSEC RRsets at a delegation point has
   a corresponding and RRSIG RR with bits in an owner name matching NSEC RR.

   Authentication examples are given in Section Appendix C.

6. IANA Considerations

   [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
   considerations introduced by DNSSEC.  The 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 [I-D.ietf-dnsext-ad-is-secure]
   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 delegated
   name, DNS security extensions use public
   key cryptography to sign and each of these RRSIG RRs is authoritative data associated
   with authenticate DNS resource record sets.
   Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
   security considerations related to DNSSEC.

   An active attacker who can set the same zone which contains CD bit in a DNS query message or
   the corresponding NSEC RRset.  If
   necessary, AD bit in a resolver DNS response message can tell use these RRSIG RRs apart by checking the
   Signer's Name field.

5.3.3 Checking the Signature

   Once bits to defeat the
   protection which 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 has validated the RRSIG RR as described in requires a secure
   channel.  See Section
   5.3.1 3.2.2 and reconstructed the original signed data as described in Section 5.3.2, 4.2 for further discussion.

   DNSSEC introduces a number of denial of service issues.  These issues
   will also be addressed in a future version of these security
   considerations.

8. Acknowledgements

   This document was created from the resolver can attempt to use input and ideas of several members
   of the cryptographic
   signature DNS Extensions Working Group and working group mailing list.
   The editors would like to authenticate express their thanks for the signed data, comments and thus (finally!)
   authenticate
   suggestions received during the RRset.

   The Algorithm field revision of these security extension
   specifications.

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.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2119]  Bradner, S., "Key words for use in the RRSIG RR identifies the cryptographic
   algorithm RFCs to generate the signature.  The signature itself is
   contained in the Signature field of the RRSIG RDATA, Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2181]  Elz, R. and the public
   key R. Bush, "Clarifications to used generate the signature is contained in the Public Key
   field DNS
              Specification", RFC 2181, July 1997.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.

   [RFC3225]  Conrad, D., "Indicating Resolver Support of the matching DNSKEY RR(s) (found DNSSEC", RFC
              3225, December 2001.

   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
              message size requirements", RFC 3226, December 2001.

   [I-D.ietf-dnsext-dnssec-intro]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "DNS Security Introduction and Requirements",
              draft-ietf-dnsext-dnssec-intro-07 (work in Section 5.3.1). progress),
              October 2003.

   [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
              Arends, R., Austein, R., Larson, M., Massey, D. and provides pointers to the documents that define each algorithm's
   use.

   Note that it is possible S.
              Rose, "Resource Records for more than one DNSKEY RR to match the
   conditions DNS Security Extensions",
              draft-ietf-dnsext-dnssec-records-05 (work in Section 5.3.1.  In this case, the resolver can only
   determine which DNSKEY RR by trying each matching key until the
   resolver either succeeds progress),
              October 2003.

Informative References

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

   [I-D.ietf-dnsext-delegation-signer]
              Gudmundsson, O., "Delegation Signer Resource Record",
              draft-ietf-dnsext-delegation-signer-15 (work in validating the signature or runs out of
   keys to try.

   If the Labels field of the RRSIG RR is not equal to progress),
              June 2003.

   [I-D.ietf-dnsext-wcard-clarify]
              Halley, B. and E. Lewis, "Clarifying the number Role of
   labels Wild Card
              Domains in the RRset's fully qualified owner name, then the RRset is
   either invalid or the result Domain Name System",
              draft-ietf-dnsext-wcard-clarify-02 (work in progress),
              September 2003.

   [I-D.ietf-dnsext-ad-is-secure]
              Wellington, B. and O. Gudmundsson, "Redefinition of wildcard expansion. DNS AD
              bit", draft-ietf-dnsext-ad-is-secure-06 (work in
              progress), June 2002.

Authors' Addresses

   Roy Arends
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   EMail: roy.arends@telin.nl
   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: mlarson@verisign.com

   Rob Austein
   Internet Software Consortium
   40 Gavin Circle
   Reading, MA  01867
   USA

   EMail: sra@isc.org

   Dan Massey
   USC Information Sciences Institute
   3811 N. Fairfax Drive
   Arlington, VA  22203
   USA

   EMail: masseyd@isi.edu

   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-8920
   USA

   EMail: scott.rose@nist.gov

Appendix A. Signed Zone Example

   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 following example shows a wildcard was applied properly.

   If other RRSIG RRs also cover this (small) complete signed zone.

   example.       3600 IN SOA ns1.example. bugs.ns1.example. (
                              1065745538
                              3600
                              300
                              3600000
                              3600
                              )
                  3600 RRSIG RR, the local resolver
   security policy determines whether the resolver also needs to test
   these  SOA 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
                              8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
                              BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
                              pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
                              LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
                  3600 NS     ns1.example.
                  3600 NS     ns2.example.
                  3600 RRSIG RRs, and determines how to resolve conflicts if these  NS 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
                              ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
                              exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
                              dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
                              BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
                  3600 MX     1 xx.example.
                  3600 RRSIG RRs lead to differing results.

   If the resolver accepts the RRset as authentic, the resolver MUST set
   the TTL of the  MX 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              CSB4g+vSxyrfsfycsZwAx2hKhwK/x7GAIY0p
                              MLBgAA/USiiMben0II4aYf5lybs0NINnFDju
                              2Kc78M8t9zBGeJcZCZEs9mKiXhW8WJanvIjg
                              BwJgWXwAnVnq20TXlsHiuwuhmtrb76/Avl4i
                              lnX6XA3eeDlQlOTuPe0B91MCuow= )
                  3600 NSEC   a.example. NS SOA MX 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 NSEC DNSKEY
                  3600 RRSIG RR's TTL as received in the response; and

   o  The value in the  NSEC 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
                              krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
                              IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
                              yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
                              2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )
                  3600 DNSKEY 256 3 1 (
                              AQPdhnap0Oj2jUq74g+vel5cukdH+wpzjiH8
                              ZOQSOHrw+s3TmbhyqXbZ/j5Uu9p65ARoevvG
                              yv459dxxZCKZ4wftXe5BUkJvZVf8HnhYW5R+
                              kQduVeqGVlkBarL5haKX28Pxvs8tV7CyY/Rd
                              cfnJlZyJcfwY0ETo4P2gntVMERZuJQ==
                              )
                  3600 DNSKEY 257 3 1 (
                              AQOwRqeRkdYUD6UCyJXTaErj0UYLHxOHlhDb
                              qik1k/j2PJFOZ7GZhc95HnYco611O5VRQ6WQ
                              pK0dL9eiwcc+gSS2L6V9pWxCfDnEPWFC6eVm
                              jRZAdAU6gsyNSZCT7rF1lAXdmWcwkaIdNaDL
                              oNqpieIQd2t+rd/oF8/++DRtzF0toQ==
                              )
                  3600 RRSIG RR's Original TTL field.

5.3.4 Authenticating A Wildcard Expanded RRset Positive Response

   If the number of labels in an RRset's fully qualified domain name is
   greater than the Labels field in the covering  DNSKEY 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              EtFrBqs8i80Ath+xOtjPHcepV/cjATf2E1fo
                              +fhSggjw2vAXDY4Sygk2tKZ9Tvhahmw1rRC3
                              CnApLvsjQ9qmnYAvkZdMILw9gPx1rBaq9d7H
                              nt7mPc/LFrO4G9JS6JNwBCnjwcxro8kNYLo6
                              97FCO3y4T7y9Hb80OvCZ36cNdps= )
                  3600 RRSIG RDATA, then the
   RRset and its covering  DNSKEY 1 1 3600 20031108232541 (
                              20031009232541 23853 example.
                              VseD0IGDKqJXiZMJnRNuq89ibF5g8VGPmMJS
                              h/hS8+nu5vLiyEObJcVxfanslAlBQSGHmJsM
                              AvXpeJUrT/zOyZ8vfy/igMhd25rnSxAD6uhl
                              4ohJiiPtFvHgLEvT0QZHizrP4wMvpXvfwn03
                              1/VEFzXZ0rULlTdWjoNzSMIYBwg= )
   a.example.     3600 IN NS  ns1.a.example.
                  3600 IN NS  ns2.a.example.
                  3600 DS     42939 1 1 (
                              4BA08982E5739A60E02B69409B0927F9524E
                              3494 )
                  3600 RRSIG RR were created as a result of wildcard
   expansion.  Once the resolver has verified the signature as described
   in Section 5.3, the resolver 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  DS 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/
                              gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp
                              zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H
                              YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c
                              iHQEOrm7yXIHwnrre1iuzMZn1jY= )
                  3600 NSEC RRs needed to authenticate the response (see Section 3.3).

5.4 Authenticated Denial of Existence   ai.example. NS DS RRSIG NSEC
                  3600 RRSIG  NSEC 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              mhov2WXDa2Swk/7/VQoI36e5OKvd/0CmMWdi
                              +3k/+i7mo9omz854ZBFMLaQzFvaS7Cn//I/H
                              7tYSY/fScUrs/UfB7le0DzdocsoaMYtexSS1
                              KA7ofbPdYpBHngIGbO5EHaGrqbKGY61fIQ/g
                              /WvT0KXnoX+v31Oq3VstBoWmizo= )
   ns1.a.example. 3600 IN A resolver can use authenticated   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 1 2 3600 20031108232541 (
                              20031009232541 5742 example.

                              MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a
                              0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn
                              KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n
                              3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F
                              UU/kYIPkm9qpSE3wtELJEq2cNsU= )
                  3600 HINFO  "KLH-10" "ITS"
                  3600 RRSIG  HINFO 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              jDn/zgIqY5ucajWNW333u+KfxORI55wvnZDs
                              pCHZQ9ISjWNT7467wUcfJKBaG+alNlCOJExg
                              z8yUS5NwySlrFtGL/CBCxmrSVioKMMetg7gP
                              Qb6x5A53OhsQAGT6azS9bdBM2RFbqBkeZkXA
                              8mJ/QOldXdH5iPpmZb2Pn47x7V4= )
                  3600 AAAA   2001:db8::f00:baa9
                  3600 RRSIG  AAAA 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1
                              ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC
                              uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG
                              qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv
                              8gB4wQFPYoozOQYTprwGtIHR2k8= )
                  3600 NSEC RRs to prove that an RRset is
   not present in a signed zone.  Security-aware name servers should
   automatically include any necessary   b.example. A HINFO AAAA RRSIG NSEC RRs for signed zones in
   their responses to security-aware resolvers.

   Security-aware resolvers MUST first authenticate
                  3600 RRSIG  NSEC RRsets
   according to the standard RRset authentication rules described in
   Section 5.3, then apply the 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              W3fFJqdRtmpz9QikpK+v5rL+Y5iNpx5H7X7c
                              1yPMlcaS0nhowHGjCPnNbCP28Ktv9I5eqhO1
                              N/A75FLTOe9L5Qzetb/C3/ME8D46apKLBEv5
                              0GWsJqTsijj4dAjup60yeLPXTWxIdO6RNdfe
                              Qd56t0fY79/kd25RzRCFGs2qHXs= )
   b.example.     3600 IN NS  ns1.b.example.
                  3600 IN NS  ns2.b.example.
                  3600 NSEC RRsets as follows:

   o  If the requested RR name matches the owner name of an
      authenticated   ns1.example. NS RRSIG NSEC RR, then the
                  3600 RRSIG  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.  Since the existence of the authenticated 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
                              0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
                              RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
                              TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
                              BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
   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 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58
                              +ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF
                              cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE
                              HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s
                              Oett68JnQVQq2l/DhWsJSjuIFBQ= )
                  3600 NSEC RR proves that the owner name exists in the zone, wildcard
      expansion could not have been used to match the requested RR owner
      name and type.

   o  If the requested RR name would appear after an authenticated   ns2.example. A RRSIG NSEC
      RR owner name and before the name listed in that
                  3600 RRSIG  NSEC RR's Next
      Domain Name field according to the canonical DNS name order
      defined in [I-D.ietf-dnsext-dnssec-records], then no exact match
      for the requested RR name exists 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 exists which
      could have been used to generate a positive response.

   To prove 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
   one 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO
                              KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L
                              zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a
                              ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk
                              o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= )
   ns2.example.   3600 IN A   192.0.2.2
                  3600 RRSIG  A 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ
                              tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4
                              mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9
                              +huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas
                              8Ic8f9zHwZmCUc0wnxX6x+422PM= )
                  3600 NSEC RRset from the zone.  If the complete set of necessary   *.w.example. A RRSIG NSEC
                  3600 RRSIG  NSEC 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              kkYPMaBn4zJM/iQAOO9i81X57MMCQnzk+pch
                              6tWUFF/D1ZFZf8QY2MzwDA5Bv/1DluWVbo3x
                              WjzyUV7fn77k9QKLQseUSXGnpyL2HR1hGfBV
                              6ZHAqJc99t5+5vjyiflLtOpA0+Ri46SlQGZf
                              IZ4X2Ksgn+hpIu77NRQMdmh59M8= )
   *.w.example.   3600 IN MX  1 ai.example.
                  3600 RRSIG  MX 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD
                              b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd
                              agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/
                              +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20
                              FxfIqrcIL24dO4Ytdz2ifqvJmuM= )
                  3600 NSEC   x.w.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9
                              7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL
                              4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH
                              yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx
                              vOHmndDhRTDwVCg179qlrEIsOgE= )
   x.w.example.   3600 IN MX  1 xx.example.
                  3600 RRSIG  MX 1 3 3600 20031108232541 (
                              20031009232541 5742 example.
                              i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d
                              NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5
                              UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r
                              uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp
                              IKZXg2219TD4UqJuRATLhxZj2fU= )
                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
   RRsets is not present in a response (perhaps due to truncation), then
   a security-aware resolver MUST resend the query in order to attempt
   to obtain the full collection of
                  3600 RRSIG  NSEC RRs necessary to verify
   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 verified 1 3 3600 20031108232541 (
                              20031009232541 5742 example.
                              VTRE+Bu91QK7dBiMshr04tE/I5HCvSrjqDv+
                              b4tlUqUqkv4MoxfoceUwavMkdLm9Pi/aYUrS
                              m6XVGBDAjpDmjivlMKNkME8c0f7oQ3E1CtHS
                              pPLjTcB9WfxEOzjJJGK5BDDT6A56P4eibLiw
                              +bNx4OGknGvVqhg9pu5qEWi814s= )
   x.y.w.example. 3600 IN MX  1 xx.example.
                  3600 RRSIG  MX 1 4 3600 20031108232541 (
                              20031009232541 5742 example.
                              yDPXa5Osa4r1AF0AjKWOo87kGNDlnVPmCbIi
                              MPvBpzJ91d5TFtEZWYJpYv+eGWZCJhK7SsnL
                              Zbbjthkn7YmX1tReDQhn8aCQ6DyrIU6wZpj5
                              ywBx0z3HGcqoYmv+AiFtcYVPxG0elsrakIwG
                              /e+CPi2yE2c9M+NnwMxhpEFVGRs= )
                  3600 NSEC RR proves the existance of both itself and its
   corresponding   xx.example. MX RRSIG RR, a verifier MUST ignore the settings of the NSEC and
                  3600 RRSIG bits in an  NSEC RR.

5.5 Examples

      Editors' note: perhaps  all of this should move to an appendix?

5.5.1 Example of Re-Constructing the Original Owner Name

   Suppose that a security-aware resolver receives a response containing
   an answer RRset with an owner name of is "www.a.b.c.example.com".
   This fully qualified domain name has 6 labels: "www", "a", "b", "c",
   "example", and "com". What name the resolver should use when
   reconstructing the original signed data depends on the value of the 1 4 3600 20031108232541 (
                              20031009232541 5742 example.
                              cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
                              R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
                              w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
                              sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
                              66FPTb3/hhrHYkMneBO2Yvfvpj8= )
   xx.example.    3600 IN A   192.0.2.10
                  3600 RRSIG RR's Labels field.

   If the value of the  A 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp
                              Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v
                              ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd
                              +N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4
                              aI16ggg9/UEWRbvn+7tp2UfMYSw= )
                  3600 HINFO  "KLH-10" "TOPS-20"
                  3600 RRSIG RR's Labels field is 6, then the  HINFO 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              vteMgDuG1ekaSmWlXlwVRoqTXjvZ8kGWCAku
                              6Rd3t/wPeVmn3YSbC8+szYRgP8n0HvYzmVYj
                              qPyC1HCFoqIJIaNLkDEyCSHuhBwpVhyKGJdM
                              EbJ1P8Yk3w5Szjap6wn7QxcLnr8Df3xUMXnB
                              AAwDzum3fUKzVM274T9O8ggeXgE= )
                  3600 AAAA   2001:db8::f00:baaa
                  3600 RRSIG RR's
   Labels field matches the number of labels in the owner name,  AAAA 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43
                              YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27
                              ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+
                              AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0
                              GxlD/3EneV4+IIIv0hekxzpR8Qs= )
                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
                  3600 RRSIG  NSEC 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              cKkFJS6Em56M0XCjMma4zFzy5ylHh2ma62oe
                              yHrqkMYS+QVUuJ8yfAoXoFbok/kDLN3rsCKK
                              ICJl1dFA3fvJnMejg0JVabQHShO2W1LmWegr
                              dh251WZQVtJHDRY8/ltYB+GHUuFpZ1CF4m+c
                              6EPqS1uLrFpRg3k4BV5y6146nZ8= )

   The apex DNSKEY set includes two DNSKEY RRs, and the
   resolver should assume DNSKEY RDATA
   Flags indicate that this RRset is not the result of wildcard
   expansion.  The resolver should therefore use "www.a.b.c.example.com"
   as the owner name when reconstructing the original signed data for
   the signature check.

   If the value each of the RRSIG RR's Labels field is less than 6, then the
   RRSIG RR's Labels count these DNSKEY RRs is less than the number a zone key.  One of labels in
   these DNSKEY RRs also has the
   RRset's owner name, SEP flag set and has been used to sign
   the resolver should assume that apex DNSKEY RRset; this RRset is the result of wildcard expansion.  The resolver should therefore
   reconstruct the original owner name by replacing the labels key which
   appear to be the result of wildcard expansion with a single "*."
   label.  For example, if the RRSIG RR's Labels field is 3, the
   resolver should reconstruct the original owner name by prepending
   "*." to the last 3 labels of the owner name of the answer RRset.
   Thus, the resolver should use "*.c.example.com" as the owner name
   when reconstructing the original signed data.

   If the value of the RRSIG RR's Labels field is greater than 6, then
   this RRSIG RR cannot possibly be valid for the answer RRset, and
   there is no point in attempting hashed to validate the signature.

5.5.2 Examples of Authenticating
   generate a Response

      Editors' note: Eventually this will be an example of the
      authentication process for "www.example.com", starting from an
      initial root key.

      Editors' note: Eventually this will DS record to be an example of the
      authentication process for non-existent "www.a.b.c.example.com",
      starting from an initial root key.

6. IANA Considerations

   [I-D.ietf-dnsext-dnssec-records] contains a review of inserted into the IANA
   considerations introduced by DNSSEC. parent zone.  The additional IANA
   considerations discussed in this document:

   [RFC2535] reserved other
   DNSKEY is used to sign all the CD and AD bits other RRsets in the message header. zone.

   The
   meaning of zone includes a wildcard entry "*.w.example".  Note that the AD bit was redefined name
   "*.w.example" is used in [I-D.ietf-dnsext-ad-is-secure] constructing NSEC chains, and that the meaning RRSIG
   covering the "*.w.example" MX RRset has a label count of both 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 CD NSEC RRset is signed.  The delegation to
   "a.example" provides a DS RR; note that only the NSEC and AD bit DS RRsets
   are restated signed.

Appendix B. Example Responses

   The examples in this
   document.  No new bits in section show response messages using the DNS message header are defined signed
   zone example in this
   document.

   [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
   and defined its use. 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 1 3 3600 20031108232541 (
                              20031009232541 5742 example.
                              i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d
                              NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5
                              UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r
                              uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp
                              IKZXg2219TD4UqJuRATLhxZj2fU= )

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
                              ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
                              exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
                              dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
                              BYpCn/jKFJ7lYnYYGLAUofh/+mo= )

   ;; Additional
   xx.example.    3600 IN A   192.0.2.10
   xx.example.    3600 RRSIG  A 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp
                              Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v
                              ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd
                              +N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4
                              aI16ggg9/UEWRbvn+7tp2UfMYSw= )
   xx.example.    3600 AAAA   2001:db8::f00:baaa
   xx.example.    3600 RRSIG  AAAA 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43
                              YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27
                              ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+
                              AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0
                              GxlD/3EneV4+IIIv0hekxzpR8Qs= )
   ns1.example.   3600 IN A   192.0.2.1
   ns1.example.   3600 RRSIG  A 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58
                              +ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF
                              cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE
                              HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s
                              Oett68JnQVQq2l/DhWsJSjuIFBQ= )
   ns2.example.   3600 IN A   192.0.2.2
   ns2.example.   3600 RRSIG  A 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ
                              tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4
                              mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9
                              +huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas
                              8Ic8f9zHwZmCUc0wnxX6x+422PM= )

B.2 Name Error

   An authoritative name error.  The use is restated but not altered in this
   document.

7. Security Considerations

   This document describes how NSEC RRs prove that the DNS security extensions use public
   key cryptography to sign name does
   not exist and authenticate DNS resource record sets.

   DNSSEC introduces a number of denial of service issues.  These issues
   will also be addressed in a future version of these security
   considerations.

   Please see [I-D.ietf-dnsext-dnssec-intro] for general security
   considerations related to DNSSEC.

8. Acknowledgements

   This document was created from 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.ns1.example. (
                              1065745538
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
                              8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
                              BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
                              pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
                              LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
   b.example.     3600 RRSIG  NSEC 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
                              0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
                              RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
                              TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
                              BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
   example.       3600 RRSIG  NSEC 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
                              krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
                              IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
                              yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
                              2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )

   ;; Additional
   ;; (empty)

B.3 No Data Error

   A "NODATA" response.  The NSEC RR proves that the input name exists and ideas of several members
   of
   that the DNS Extensions Working Group and working group mailing list.
   The co-authors of this draft would like 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.ns1.example. (
                              1065745538
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
                              8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
                              BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
                              pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
                              LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
   ns1.example.   3600 RRSIG  NSEC 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO
                              KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L
                              zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a
                              ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk
                              o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= )

   ;; Additional
   ;; (empty)

B.4 Referral to express their thanks for Signed Zone

   Referral to a signed zone.   The DS RR contains the comments and suggestions received during data which the revision of these
   security extension specifications.

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.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [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
   resolver will need to validate the DNS
              Specification", RFC 2181, July 1997.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, 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.

   [I-D.ietf-dnsext-dnssec-intro]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "DNS Security Introduction and Requirements",
              draft-ietf-dnsext-dnssec-intro-06 (work corresponding DNSKEY RR in progress),
              September 2003.

   [I-D.ietf-dnsext-dnssec-records]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "Resource Records the
   child zone's apex.

   ;; Header: QR DO RCODE=0
   ;;
   ;; 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     42939 1 1 (
                              4BA08982E5739A60E02B69409B0927F9524E
                              3494 )
   a.example.     3600 RRSIG  DS 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/
                              gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp
                              zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H
                              YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c
                              iHQEOrm7yXIHwnrre1iuzMZn1jY= )

   ;; 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 DNS Security Extensions",
              draft-ietf-dnsext-dnssec-records-04 (work
   this delegation exists in progress),
              September 2003.

Informative References

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures 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 1 2 3600 20031108232541 (
              SIG(0)s)", RFC 2931, September 2000.

   [I-D.ietf-dnsext-delegation-signer]
              Gudmundsson, O., "Delegation Signer Resource Record",
              draft-ietf-dnsext-delegation-signer-15 (work
                              20031009232541 5742 example.
                              csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
                              0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
                              RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
                              TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
                              BFydo6dXwQ4WK8OUC6sMCM+OHEg= )

   ;; 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 which was answered via wildcard expansion. The
   label count in progress),
              June 2003.

   [I-D.ietf-dnsext-wcard-clarify]
              Halley, B. the answer's RRSIG RR indicates that a wildcard RRset
   was expanded to produce this response, and E. Lewis, "Clarifying the Role 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 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD
                              b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd
                              agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/
                              +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20
                              FxfIqrcIL24dO4Ytdz2ifqvJmuM= )

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
                              ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
                              exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
                              dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
                              BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
   x.y.w.example. 3600 RRSIG  NSEC 1 4 3600 20031108232541 (
                              20031009232541 5742 example.
                              cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
                              R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
                              w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
                              sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
                              66FPTb3/hhrHYkMneBO2Yvfvpj8= )

   ;; Additional
   ai.example.    3600 IN A   192.0.2.9
   ai.example.    3600 RRSIG  A 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a
                              0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn
                              KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n
                              3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F
                              UU/kYIPkm9qpSE3wtELJEq2cNsU= )
   ai.example.    3600 AAAA   2001:db8::f00:baa9
   ai.example.    3600 RRSIG  AAAA 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1
                              ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC
                              uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG
                              qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv
                              8gB4wQFPYoozOQYTprwGtIHR2k8= )

B.7 Wildcard No Data Error

   A "NODATA" response for a name covered by a wildcard.  The NSEC RRs
   prove that the matching wildcard name does not have any RRs of Wild Card
              Domains in the Domain Name System",
              draft-ietf-dnsext-wcard-clarify-01 (work in progress),
              August 2003.

   [I-D.ietf-dnsext-ad-is-secure]
              Gudmundsson, O.
   requested type and B. Wellington, "Redefinition of DNS AD
              bit", draft-ietf-dnsext-ad-is-secure-06 (work that no closer match exists in
              progress), June 2002.

Authors' Addresses

   Roy Arends
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   EMail: roy.arends@telin.nl
   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: mlarson@verisign.com

   Rob Austein
   Internet Software Consortium
   40 Gavin Circle
   Reading, MA  01867
   USA

   EMail: sra@isc.org

   Dan Massey
   USC Information Sciences Institute
   3811 N. Fairfax Drive
   Arlington, VA  22203
   USA

   EMail: masseyd@isi.edu

   Scott Rose
   National Institute 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.ns1.example. (
                              1065745538
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
                              8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
                              BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
                              pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
                              LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
   x.y.w.example. 3600 RRSIG  NSEC 1 4 3600 20031108232541 (
                              20031009232541 5742 example.
                              cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
                              R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
                              w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
                              sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
                              66FPTb3/hhrHYkMneBO2Yvfvpj8= )
   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
   *.w.example.   3600 RRSIG  NSEC 1 2 3600 20031108232541 (
                              20031009232541 5742 example.
                              fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9
                              7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL
                              4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH
                              yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx
                              vOHmndDhRTDwVCg179qlrEIsOgE= )

   ;; Additional
   ;; (empty)

B.8 DS Child Zone No Data Error

   A "NODATA" response for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-8920
   USA

   EMail: scott.rose@nist.gov a QTYPE=DS query which 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.ns1.example. (
                              1065745538
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
                              8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
                              BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
                              pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
                              LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
   example.       3600 RRSIG  NSEC 1 1 3600 20031108232541 (
                              20031009232541 5742 example.
                              10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
                              krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
                              IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
                              yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
                              2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )

   ;; Additional
   ;; (empty)

Appendix A. Algorithm For Handling Wildcard Expansion

   For zone (Z) and a name (N) that may occur C. Authentication Examples

   The examples in Z, this section show how the following
   algorithm finds all wildcard RRsets that match N or returns response messages in
   Appendix B are authenticated.

C.1 Authenticating An Answer

   The query in section Appendix B.1 returned an NSEC MX RRset that proves no wildcard expansion matches N. for
   "x.w.example.com". The corresponding RRSIG indicates the MX RRset was
   signed by an "example" DNSKEY with algorithm 1 and key tag 5742.  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
   written 3600 and,
   for clarity, the purpose of authentication, the current TTL is replaced by
   3600.   The RRSIG labels field value of 3 indicates the answer was
   not efficiency:

         0. INPUT: a name (N) and a zone (Z).
            INIT: NSEC_SET = NULL

         1. Construct S = sequence the result of all names wildcard expansion.  The "x.w.example.com" MX RRset
   is placed in Z, sorted
                          into canonical order.

         2. If N exists in S
               There form and, assuming the current time falls
   between the signature inception and expiration dates, the signature
   is an exact match for N.
               Return all RRsets associated with N
            Else
               Add authenticated.

C.1.1 Authenticating the name example DNSKEY RR

   This example shows the logical authentication process that would immediately
               precede N in S to NSEC_SET.
            EndIf

         3. Replace starts
   from the leftmost label of N with *

         4. If N exists in S a preconfigured root DNSKEY (or DS RR) and answers moves down the query
               There
   tree to authenticate the desired "example" DNSKEY RR.   Note the
   logical order is a positive wildcard match presented for N.
               Return clarity and an implementation may
   choose to construct the authentication as referrals are received or
   may choose to construct the authentication chain only after all
   RRsets associated 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 N
            Else
               Add an preconfigured DNSKEY RR for the NSEC
   root zone (or a preconfigured DS RR for name that would immediately
               precede N the root zone).  The resolver
   checks this preconfigured DNSKEY RR is present in S to NSEC_SET.
               Return the NSEC_SET.
            EndIf

         5. Remove root DNSKEY
   RRset (or the leading * from N.

         6. If N exists DS RR matches some DNSKEY in S
               There is a name that terminates the wildcard search.
               Add root DNSKEY RRset),
   this DNSKEY RR has signed the NSEC for N to NSEC_SET root DNSKEY RRset and return NSEC_SET.
            Else
               Add the NSEC for name that would immediately
               precede N signature
   lifetime is valid.  If all these conditions are met, all keys in S to NSEC_SET.
               Return the NSEC_SET.
            EndIf

Appendix B. Signed Zone Example

   The following example shows a (small) complete signed zone.

   example.       3600 IN SOA ns1.example. bugs.ns1.example. (
                              1064876255
                              3600
                              300
                              3600000
                              3600
                              )
                  3600 RRSIG  SOA 1 1 3600 20031029215736 (
                              20030929215736 4638 example.
                              Bo6PBV6UOrnCzptCZg0lTQQqsZ4qqIn16vbA
                              KQobYD2wNxs5hxNYlvNRlNPB0nfSD9o2daBE
                              v0Q/Q5mEanr2R28a62PHwkHNwHUx/spGWAGJ
                              h5u28d5wMNQQvMsFgB+kSSnNEcL1Z7uLjRal
                              ahgGvtiSMzzSS7n65xfxc1X78Nw= )
                  3600 NS     ns1.example.
                  3600 NS     ns2.example.
                  3600 RRSIG  NS 1 1 3600 20031029215736 (
                              20030929215736 4638 example.
                              WeJdApmzK+GIrOQKYmkABF5POWu5SDU6opwd
                              wOjWrVFGRNhFHe1Z/KZwT1Ii5YjH2X9dTRRh
                              YG3U/wcqvWLJ1882FoUZakwmtzGFotdONcs3
                              DzhFMxTawVlBb+MLsPj8J2GuZiR28eTyPB6i
                              TYq3Ed0R9VStJwtiKmoXqubFAr0= )
                  3600 MX     1 xx.example.
                  3600 RRSIG  MX 1 1 3600 20031029215736 (
                              20030929215736 4638 example.
                              eBXNS2Vi/MhqX76VCIlpbK4yq9UWzvYcSBV9
                              Cx0t6rl9CWOpdFVzV/lL0wyVYQjZXBlZ1gpo
                              djLXl0QTEE+9MrRO3c8j7NyVsOEJQdnWdEAW
                              BL8f+F3fwayjj5dIsq1NngF8neGXROao1bJM
                              5gmIc/F6gzUL3/KyJA8zPF2fUVA= )
                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC
                  3600 RRSIG  NSEC 1 1 3600 20031029215736 (
                              20030929215736 4638 example.
                              t3VabTtmQ3uEgohzbuHKk2bFEDqYWa3hgTi2
                              D1Sv+eN+IkV1xExBvsvuE6Oovf+QlDqV7sU/
                              XP2kRzob5V9N40xQCZMBFx2GgAim8px788EX
                              ZuS7u0fKeHfaP/2sSTktGnpK77Mx4fM6RK8x
                              DBRONckIWXn2chGDeicQuEHjhfQ= )
                  3600
   DNSKEY 256 3 1 (
                              AQPbGuRKgswzNd2Qb7ck1Tdai9FFbapP3mUO
                              G80mSowM5s9aMao+JOeFl/4f33cs2hWHznn3
                              LZ5EuIlA/lvvG+f5h46OvCR+CFXHmqEPyMmd
                              kiCdJmHcvRuMIzekHM2DSDcG7i1lZG/jXvaG
                              mK5G3NeHjqssh1AujDaqHFf5IRIeQQ==
                              )
                  3600 RRset are considered authenticated.   The resolver then uses
   one (or more) of the root DNSKEY 257 3 1 (
                              AQPGkQLwyHHfD8nkDxZSbErTBHLYdOKkVIoq
                              SJkBnpfABtFdiJBgZYcjCNExAFjlc/olW42g
                              TJYBRjs1INw3I08/h43L595Iq8fyhEyBoGOR
                              +6db+Q3oQ9G2EKpfMEPDLU6f7gYrHpzDHIjO
                              rsSftzmRYHou70oVQ7aBjd9ePPCOVw==
                              )
                  3600 RRSIG RRs to authenticate the "example" DS
   RRset.  Note the resolver may need to query the root zone to obtain
   the root DNSKEY 1 1 3600 20031029215736 (
                              20030929215736 4638 example.
                              GMZI2r4bwFYpKIs0Dv//4aWg5HhpzMBkm5Vk
                              4KFg4hEkOabYgWoBJdZdjRBTrjwkrtiPH9KF
                              kJKlzFfeeELbFEfhgZ3SujDqNQmGfoZ1i7a2
                              lH47jc1JOeos75e9QK8fUFjIxOF8fkZNO9Fx
                              lOyOxNDJPATE3Wm+AX0SmQSJ3XY= )
   a.example.     3600 IN NS  ns1.a.example.
                  3600 IN NS  ns2.a.example.
                  3600 RRset and/or "example" DS     23677 1 1 (
                              F248F32298280A061736C93FB078A51C17CC
                              C291 )
                  3600 RRSIG RRset.

   Once the DS 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              k6fA3VfeR5UHu9L/+4y8HJrUubVHBdyFzMaa
                              8EpDYqw3vYEVsrL5YvXwoqrSZsSAxdIrUXoB
                              SzjbKFOq6HRxXjuLsJ2TLT90p6mg9ZHL57jH
                              FfmrNPuq58QwRWvwuOyaExJWEdxMIEIbvETz
                              YJs3G/9tNte9i25YtAuLHbD2UqY= )
                  3600 NSEC   ai.example. NS 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 RRSIG NSEC
                  3600 RRSIG  NSEC 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              tQbGVL6yxb2vBQ5ItcQ1XQyxNxz3+zHTTkgs
                              T/WSk9YXr+swug7h+Wq20RPXfsEl7lVMi/By
                              d60s6Q7lEibGucIQCLLx0Xe68zQOmWx7fmU6
                              iSDTQgc7TOsG/blDba7MiRENTeI6iynyZHw9
                              gURpK8RlfEPb7O98rrYLWZbzg3o= )
   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 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              UCegsbGngHOwgyxevtBrCSsV6Jv6OxGWApvY
                              RsbwL2XZBFc4saU6Zujiz8i2urkVLSlFM2MM
                              OHuEMN5E+cjGDjqfaI8O5eILapsGRqHUPM9t
                              5wCOb9BqANn03UUFUhAnKBkv3fHFM5hg+IZQ
                              vVNUzslGEBlQ0SJZkWJcCtRDo5c= )
                  3600 HINFO  "KLH-10" "ITS"
                  3600 RRSIG  HINFO 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              CP6bRkIyQ3FnhsBWO63uQN1QtJse8mWNRTf2
                              jXqR33dekEfKNhlQtw0yzepa7lX75uyQTAlP
                              NBBK73Zlim5g1bw3ulLl0vXnTpQRSK80SJw9
                              uPPTYBDq68jMKn1a3RvGnR5MynQR33UY2vGT
                              6IAiGfqY/zYFXWSIsmJr0875PQ0= )
                  3600 AAAA   2001:db8::f00:baa9
                  3600 RRSIG  AAAA 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              VnpRe+HGt+mCalDopO4wtHtRvs9CKdjr3FoG
                              zv8BPFvC1FdDJAjxpAgJs6Ihx+174Hl+jlZU
                              Z3HOd0MBwch0XH1UDcU0/opQRquW+oYwV3E4
                              esgKhsy9EUj3NtoW/GQ/1dJEbuUZah4/IPGH
                              KI0DhRWJC/iKs6J963WLNdPnwKk= )
                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
                  3600 RRSIG  NSEC 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              A7MtS+oATUFf6t3nj/0GL7lBbt86ozzkbbJM
                              J3tLwFkGebf1XV+MnpPeSzeRXm4QeqohDvVZ
                              U5SluyOHT397x4WQPwHCRXojos1lQnWhPUji
                              qjKaXLVRHv4x2O2fzWu0OE65GJkL6zAnFqCL
                              SpV8hBOC+EAcLjnuAi5DJJlONmc= )
   b.example.     3600 IN NS  ns1.b.example.
                  3600 IN NS  ns2.b.example.
                  3600 NSEC   ns1.example. NS RRSIG NSEC
                  3600 RRSIG  NSEC RRs.  If such a
   matching "example" DNSKEY is found, the resolver checks this DNSKEY
   RR has signed the "example" DNSKEY RRset and the signature lifetime
   is valid.  If all 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 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              lGZ+rJ1vtIEtLjXKG4Iruipq6KoXrre89QHZ
                              dBgSPcomROrsSElhUBFLcl2+KMCnKCqtEJZ7
                              YPOTK07WCwFU6Rek+xD+OuuJrQRWTbiCmFMX
                              N9ZMk87lkIWHAXMk1YM3f1/FUytbb8RI8RfH
                              u2x/e3zoBQdHAId3LCOO9jYDzCc= )
   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 and has a key tag of 5742.  This DNSKEY
   is used to authenticated the RRSIG  A included in the response.  If
   multiple "example" DNSKEY RRs have algorithm 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              u/uV4xcu7KSVV+3Vtg8O0qTGlGHeFKU1vBQJ
                              x1QKLtolw/ZstzqIuRBI5fuF4JYxSwMoaI7b
                              JBFyZ3KkCCK88r1VjZTkicNvFG7RO3G2faxb
                              MualMbGfhcexJzRcoZsIXSb3+qtbAr4aKF7c
                              fdZ587NLR1Ns2GraGTztUDMSK/A= )
                  3600 and key tag of 5742,
   then each DNSKEY RR is tried and the answer is authenticated if
   either DNSKEY RR validates the signature as described above.

C.2 Name Error

   The query in section Appendix B.2 returned NSEC   ns2.example. A RRSIG RRs that prove the
   requested data does not exist and no wildcard applies.  The negative
   reply is authenticated by verifying both NSEC
                  3600 RRSIG RRs. The NSEC 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              bsz0NVY6tQ0kmIpKOR3QHNEradwR39uNikey
                              jQIr7TMOvNVDX6tVBNoDuKxUy6zHR5CS6oBs
                              nN5OPPKEjTdOGWUfHavSZgZGT7b8xfL++Ahi
                              Cgeg0ofB6Ext7KfeMkTrxP/8BsDMJm8R8Ome
                              I2mIq/WvuXTr2XKcJDbxYIdSyss= )
   ns2.example.   3600 IN A   192.0.2.2
                  3600 RRSIG  A 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              mCzjw1wydcnYx0d7kbPbJTXVw+FnksdLnTmq
                              DrIdy269MeGL4AGJSV8g8Gt0Zbq3hGo6+/Tz
                              S9VIp4QZtKgRZ1nlI0XQOlkASOLPjvo7hHRr
                              PPiFqGyznqy9+QHdIalqTO4BOrfS3f5bIgJW
                              IGUMRh8nFi+wnG09+OH46IlkB9s= )
                  3600 RRs are
   authenticated in a manner identical to that of the MX RRset discussed
   above.

C.3 No Data Error

   The query in section Appendix B.3 returned an NSEC   *.w.example. A RRSIG RR that proves the
   requested name exists, but the requested RR type does not exist. The
   negative reply is authenticated by verifying the NSEC
                  3600 RRSIG RR.  The NSEC 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              FS6W/8Na26DIs1DYB1Xhhxc1GyRlzj5XkG/3
                              pY6H6PQGc/nP6CVM1eHEkmvYAG8kWfk9ZdDZ
                              64cOb2tisSH1o7WMLg7hWUS5nnXyxyyj5/Gs
                              n3CpVCDptq9JnQe+jjH0empKdbTYoeVIX8h/
                              2aw1RkmYb4LbuhP0uwN/lZqQVik= )
   *.w.example.   3600 IN MX  1 ai.example.
                  3600 RRSIG
   RR is authenticated in a manner identical to that of the MX 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              MHxP6z3ozpA9AICDnEW0T06o2GlIOtj0+oGm
                              TC4nqveQj2QSKOEUNXgVaUkBTT9F/FIVy9q+
                              FAAe4SXnBcVpIvTVN2NhU4Jm9976hU8HTEfi
                              EMlnhmn4vJ1qZ+DI1WgWK+iKSU/N6ShdN/Fi
                              G7zd/X4PmuWIIYG+5IAzmtB2UJs= )
                  3600 NSEC   x.w.example. RRset
   discussed above.

C.4 Referral to Signed Zone

   The query in section 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 RRSIG NSEC
                  3600 RRSIG 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 this DNSKEY
   RR has signed the "a.example" DNSKEY RRset and 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 section Appendix B.5 returned a referral to an unsigned
   "b.example." zone.  The NSEC 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              tXBqjlbdFl70S+dzovir86EQBHavroozeo4f
                              Spsc9BlorSdTTSwbf7lh+GRIS0hCtaJxMFog
                              0XhGhO6sn1Yai3s7NeV6viQpy8gPfJ0wfr9Y
                              H1nYv76o6oXX2KlGTJrd4J7f7Hxz2DsOWVoK
                              w1LXOATBvP/kCRgmq4KdFNwTiBc= )
   x.w.example.   3600 IN MX  1 xx.example.
                  3600 RRSIG  MX 1 3 3600 20031029215736 (
                              20030929215736 4638 example.
                              p/BQOuDk4Wg3pZreH6kmxws0A1hNYIkJTTlP
                              rHoI9T/HMfA50p/qnXQHxgYh1IDnsxjeswaE
                              LL7B/q0QxmaT1/0wNbZTn58/rqDSpV43Qxjl
                              QHK0fDgp6al4VNxvK+uIJIHO525jCH146BEC
                              +tqUhrmtTxtItfpV/8Q7i6+B2bY= )
                  3600 proves that no authentication leads from
   "example" to "b.example" and the NSEC   x.y.w.example. RR is authenticated in a manner
   identical to that of the MX RRset discussed above.

C.6 Wildcard Expansion

   The query in section Appendix B.6 returned an answer that was
   produced as a result of wildcard expansion.   The RRset expanded as
   the similar to The corresponding RRSIG NSEC
                  3600 RRSIG  NSEC 1 3 3600 20031029215736 (
                              20030929215736 4638 example.
                              c2/unp4ewGHNJIOVKiw9O/aA+PfXJ5Thwjt4
                              EyleUaXFp01H5RkDVxMVicJEHcfslqfzF8XP
                              M9pPTwU7DPAFrxXo71pMez/EqA3pnhxnUcEi
                              lVextpfIxIZam0Oj5Q+nCLJJs95Q3I8E5J29
                              IgHVoBYahu8hE0DycgzLredhC5A= )
   x.y.w.example. 3600 IN indicates the MX RRset was
   signed by an "example" DNSKEY with algorithm 1 xx.example.
                  3600 and key tag 5742.  The
   RRSIG indicates the original TTL of the MX 1 4 3600 20031029215736 (
                              20030929215736 4638 example.
                              nwe5rxko6mbV2f0edTn0/H1CbDd8T4ZHg2Wg
                              Os3Lh5Rz092PVbAnbzCp4Y95MdPPwMUd3cKk
                              h7tvjBJgPPBhAWufdv2uVcq2lnINs1+LsJH7
                              CtJobsu9LxcORCkcYEKG1bc4fInPPnuUnlXD
                              JYEmK1UOpYTDRx+lKLRI5tLzKmc= )
                  3600 NSEC   xx.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 1 4 3600 20031029215736 (
                              20030929215736 4638 example.
                              UjlRFPbR2LzHtiP+CDGsJnaSo0iyooOkZ2By
                              vyqOGHg+0OudJ4/+VYC/8C0dJNRUzAAm17GG
                              ox272n3P0BHERCeegWAFCjYCARhZwkfpq8sQ
                              ynkJRjpFlkxgdSFiHDZOAQz/s0a9ZaFDKP27
                              rKbS4qvhL+dfOnPBPNI099W7EAw= )
   xx.example.    3600 IN A   192.0.2.10
                  3600 RRSIG  A 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              irvnPlRadiUTTM3feA/mNNKnxRIRY7vZ0r3d
                              foc+IgbvYJeHi8UYThPrinjF2SPcwQ29g+6h
                              aFA8ne9ZpRwL1lEQ6U3OTGLKd1OtGCTizEmN
                              fgmPU/wIUuNaR7AG4i6FekWhciHbrjfRF/NN
                              zJKlxAUeVRQ2ufYCoSY7wa6cIV4= )
                  3600 HINFO  "KLH-10" "TOPS-20"
                  3600 RRSIG  HINFO 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              NL6VSnSkuPX41EgJChuPiVF9JzIsJ/p7pQ61
                              DG8oWhtZjTP1uYWdwHPMM3EDxQykJBwJShE9
                              5Mg7myUpRFAuLHZJZ35227AZ6+eo0UoikJSA
                              opuXW50OLYARZTy4lRqSUU41B5Km1vvYaIoq
                              hjNlRggyhvEmSNw4kvl5w99jqKg= )
                  3600 AAAA   2001:db8::f00:baaa
                  3600 RRSIG  AAAA 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              wkkCfIYfNeQ2YK0fL/bceo9oONGfZNkp/MnQ
                              yllq11xEoelJbWjqlS7RbfUViOVbrxJbV+8j
                              AYnLEC3/YGdoDUeVBPk2hqfGB8vMZfsu/d1Y
                              bhcMej6fIoXj/q4HIXNSD9UcP0CNtLR6n7Bq
                              ndtF5V/pM6xI0tiE51KudVttsJI= )
                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
                  3600 RRSIG  NSEC 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              fi2La99VLlZhIPUgGd/Fd6MH8wJZ6ziSPW34
                              k214lDIQQBlu0X4V0z4DcZ/PDBeqvKOORmEI
                              AhZLwELtWv5XSAmALYUr3Rrtp/H066R4EpAu
                              YrS4pZ8/QFM+HnPUcofSK3IzLBucXsnDSYr0
                              fQ5nfoBQ++eHo+IEohbqrwnE60E= )

   The apex DNSKEY set includes two DNSKEY RRs, and RRset was 3600 and, for
   the DNSKEY RDATA
   Flags indicate that each purpose of these DNSKEY RRs authentication, the current TTL is a zone key.  One replaced by 3600.
   The RRSIG labels field value of
   these DNSKEY RRs also has the SEP flag set and has been used to sign 2 indicates the apex DNSKEY RRset; this is answer the key which should be hashed to
   generate a DS record to be inserted into result of
   wildcard expansion since the parent zone. "a.z.w.example" name contains 4 labels.
   The other
   DNSKEY name "a.z.w.w.example" is used to sign all replaced by "*.w.example", the other RRsets MX RRset
   is placed in canonical form and, assuming the zone. current time falls
   between the signature inception and expiration dates, the signature
   is authenticated.

   The zone includes a wildcard entry "*.w.example".  Note NSEC proves that no closer match (exact or closer wildcard) could
   have been used to answer this query and the name
   "*.w.example" NSEC RR must also be
   authenticated before the answer is used considered valid.

C.7 Wildcard No Data Error

   The query in constructing section Appendix B.7 returned NSEC chains, and RRs that prove the RRSIG
   covering the "*.w.example" MX RRset has a label count of 2.
   requested data does not exist and no wildcard applies.  The zone also includes two delegations. negative
   reply is authenticated by verifying both NSEC RRs.

C.8 DS Child Zone No Data Error

   The delegation to
   "b.example" includes an NS RRset, glue address records, and an query in section Appendix B.8 returned NSEC
   RR; note RRs that only shows the
   requested was answered by a child server ("example" server).   The
   NSEC RRset RR indicates the presence of an SOA RR, showing the answer is signed.  The delegation to
   "a.example" provides a DS RR; note that only
   from the NSEC and child .  Queries for the "example" DS RRsets
   are signed. RRset should be sent
   to the parent servers ("root" servers).

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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