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

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

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.

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

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

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

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

Copyright Notice

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

Abstract

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

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

Table of Contents

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

1. Introduction

   The DNS Security Extensions (DNSSEC) modify several aspects are a collection of new resource
   records and protocol modifications which add data origin
   authentication and data integrity to the
   DNS protocol. 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
   functions. Finally, Section 5 defines how to use DNSSEC RRs to
   authenticate a response.

1.1 Background and Related Documents

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

   This document is part of a family of documents which define the DNS
   security extensions (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and protocol modifications which
   add data origin authentication and data integrity to the DNS. DNSSEC.
   An introduction to DNSSEC and definition of common terms can be found
   in
   [9]. [I-D.ietf-dnsext-dnssec-intro].  A definition of the DNSSEC
   resource records can be found in
   [10].  This document defines the DNSSEC protocol modifications. [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.  [4]. [RFC2119].

1.3 Editors' Notes

1.3.1 Open Technical Issues

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

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

1.3.2 Technical Changes or Corrections

   Please report technical corrections to 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 defines is built around the concept of a signed zone. zones.  A signed zone
   includes
   KEY, SIG, NXT DNSKEY, RRSIG, NSEC and (optionally) DS records according to
   the rules specified in Section 2.1, Section 2.2, Section 2.3 and
   Section 2.4, respectively.  Any zone which does not include these
   records according to the rules in this section must be considered unsigned.

      Editors' note: Should this be "MUST MUST be considered unsigned"?
   unsigned for the purposes of the DNS security extensions.

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

   Section 2.6 shows a sample signed zone.

2.1 Including KEY DNSKEY RRs in a Zone

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

   To sign a zone, the zone's administrator generates one or more
   public/private key pairs and uses the private key(s) to sign
   authoritative RRsets in the zone.  For each private key used to
   create SIG RRSIG RRs, there SHOULD be a corresponding KEY zone DNSKEY RR
   stored at the
   zone apex.  All KEY RRs at in the zone apex MUST be zone keys.  (A zone.  A zone key KEY DNSKEY RR has the Zone Key bit of the Flags
   flags RDATA field set to one.
   See one -- see Section 2.1.1 of [10].)  Zone key KEY
   [I-D.ietf-dnsext-dnssec-records].  Public keys associated with other
   DNS operations MAY be stored in DNSKEY RRs MUST appear only at that are not marked as
   zone keys.

   If the zone apex.

   A signed is delegated and does not wish to act as an island of
   security, the zone MUST have at least one zone key KEY DNSKEY RR in its at the apex KEY
   RRset. to
   act as a secure entry point into the zone.  This DNSKEY would then be
   used to 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).  The KEY DNSKEY RRset at the zone apex MUST be self-signed signed by
   at least one private key whose corresponding public key is a zone key
   stored in the apex KEY RRset.

      Editors' note: The requirement listed signing or DNSKEY signing private key.

   DNSKEY RRs MUST NOT appear at delegation points.

2.2 Including RRSIG RRs in this paragraph may not be
      necessary anymore, since the KEY a Zone

   For each authoritative RRset is self-signed anyway
      (because the whole zone is signed).  This is probably a pre-DS
      relic, but we spotted this a few hours before the I-D deadline and
      were too chicken to remove it on such short notice....

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

2.2 Including SIG RRs in a Zone

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

   o  The SIG RRSIG owner name is equal to the RRset owner name;

   o  The SIG RRSIG class is equal to the RRset class;
   o  The SIG RRSIG Type Covered field is equal to the RRset type;

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

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

   o  The SIG RRSIG Labels field is equal to the number of labels in the
      RRset owner name, not counting the null root label or any and not
      counting the wildcard
      label; label if the owner name is a wildcard;

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

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

   The process for constructing the SIG RRSIG RR for a given RRset is
   described in [10]. [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
   multiple SIG RRSIG RRs associated with it.

   A SIG

   An RRSIG RR itself MUST NOT be signed, since signing a SIG RRset an RRSIG RR
   would add no value and would create an unterminated dependency infinite loop in the signing
   process.

   The NS RRset which appears at the zone apex name MUST be signed, but
   the 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 signed. Glue address RRsets associated with
   delegations MUST NOT be signed.

   The difference between the set of owner names which require SIG RRSIG
   records and the set of owner names which require NXT NSEC records is
   subtle and worth highlighting.  SIG  RRSIG records are present at the
   owner names of all authoritative RRsets.  NXT  NSEC records are present at
   the owner names of all names for which the signed zone is
   authoritative and also at the owner names of delegations from the
   signed zone to its children.  Neither NXT NSEC nor SIG RRSIG records are
   present (in the parent zone) at the owner names of glue address
   RRsets.  Note, however, that this distinction is for the most part
   only visible during the zone signing process, because NXT NSEC RRsets are
   authoritative data, and
   therefore are therefore signed, thus any owner name
   which has an NXT NSEC RRset will have SIG RRSIG RRs as well in the signed
   zone.

2.3 Including NXT NSEC RRs in a Zone

   Each owner name in the zone MUST have an NXT NSEC resource record, except
   for the owner names of any glue address RRsets.  The process for
   constructing the NXT NSEC RR for a given name is described in [10].
   [I-D.ietf-dnsext-dnssec-records].

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

2.4 Including DS RRs in a Zone

   The DS resource record establishes authentication chains between DNS
   zones.  A DS RRset SHOULD be present at a delegation point when the
   child zone is signed.  The DS RRset MAY contain multiple records,
   each referencing a key used by the child zone to sign its apex KEY DNSKEY
   RRset.  All DS RRsets 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 to a KEY DNSKEY RR which is present in the child's
   apex
   KEY DNSKEY RRset, and the child's apex KEY DNSKEY RRset SHOULD be signed
   by the corresponding private key.

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

2.5 Changes to the CNAME Resource Record.

   If a CNAME RRset is present at a name in a signed zone, appropriate
   SIG
   RRSIG and NXT NSEC RRsets are REQUIRED at that name. Other types MUST NOT
   be present at that name.

   This is a modification to the original CNAME definition given in [1].
   [RFC1034].  The original definition of the CNAME RR did not allow any
   other types to co-exist with a CNAME record, but a signed zone
   requires NXT NSEC and
   SIG RRsets RRSIG RRs for every authoritative name.  To resolve
   this conflict, this specification modifies the definition of the
   CNAME resource record is hereby modified to allow for the co-existence of NXT it to co-exist with NSEC and SIG RRsets. RRSIG
   RRs.

2.6 Example of a Secure Zone

      {{secure zone here}}

      Editors' note: Zone file example deferred pending hackery to add
      zone files in a format usable by xml2rfc.  Goal here is to show

   Appendix B shows a
      (small) complete example of a small signed zone.

   The apex KEY set includes two KEY RRs, and

3. Serving

   This section describes the KEY RDATA Flags
   indicate that each behavior of these KEY RRs is a zone key.  The first zone
   KEY is used to sign security-aware authoritative
   name server.  A security-aware authoritative name server MUST support
   the apex KEY RRset, EDNS0 [RFC2671] message size extension, MUST support a message
   size of at least 1220 octets, and SHOULD support a DS record for this key
   is provided to the parent zone.  The second zone KEY is used to sign
   all the other RRsets in the zone.  A non-zone KEY RR is also stored
   at "host1.example.com"; this KEY might be used by SIG(0) to
   authenticate transactions from this host.

   The zone includes a wildcard entry "*.a.example.com".  Note that the
   "*.a.example.com" name is used in constructing NXT chains, and that
   the SIG covering the "*.a.example.com" MX RRset has a label count of
   3.

   The zone also includes two delegations.  The delegation to
   "insecure.example.com" includes an NS RRset, glue address records,
   and an NXT RR, but note that only the NXT RRset is signed.  The
   "secure.example.com" delegation provides a DS RR, and note that only
   NXT and DS RRsets are signed.

3. Serving

   This section describes the behavior of a security-aware authoritative
   name server.  A security-aware authoritative name server MUST support
   the EDNS0 [6] message size extension, MUST support a message size of
   at least 1220 octets, and SHOULD support a message size of 4000
   octets [8].  Since functions specific message size of
   4000 octets [RFC3226].  Since functions specific to security-aware
   recursive name servers included components of both resolving and
   serving, issues specific to security-aware recursive name servers are
   described in Section 4.

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

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

   o  NXT  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 NXT NSEC RR proving that no DS RRs exist MUST be
      included in referrals automatically according to the rules in
      Section 3.4.

   DNSSEC does not change the DNS zone transfer protocol.  Zone transfer
   requirements are reviewed in Section 3.6.

   A security-aware name server which receives a DNS query which does
   not include the EDNS OPT pseudo-RR, pseudo-RR or which has the DO bit set to
   zero,
   zero MUST treat the SIG, KEY, RRSIG, DNSKEY, and NXT NSEC RRs as it would any other
   RRset, and MUST NOT perform any of the additional processing
   described above.  Since the DS RR type has the peculiar property of
   only existing in the parent zone at delegation points, DS RRs always
   require some special processing, as described in Section 3.5.

3.1 Including SIG RRSIG RRs in a Response

   When a query has the DO bit set to one, the authoritative name server
   SHOULD attempt to send SIG RRSIG RRs which can be used to authenticate
   the RRsets in the response.  Inclusion of SIG RRSIG RRs in a response is
   subject to the following rules:

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

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

   o  When placing a signed RRset is placed in the Additional section, the name
      server MUST also place its SIG RRSIG RRs are also placed in the Additional section.
      If space does not permit the inclusion of these SIG RRSIG RRs, the response name
      server MUST NOT be
      considered truncated just set the TC bit solely because these SIG RRSIG RRs
      didn't fit.

3.2 Including KEY DNSKEY RRs In a Response

   When a query has the DO bit set to one and requests the SOA or NS RRs
   at the apex of a signed zone, then a security-aware authoritative name
   server for that zone SHOULD MAY return the KEY DNSKEY RRset with the same name
   in the Additional section.  If Additional section processing
   results in more data than will fit in  In this situation, the response message, address
   glue DNSKEY RR set and
   associated RRSIG RRs have higher lower priority than KEY RRs.  SIG RR(s) associated
   with the KEY RRset SHOULD also any other information
   that would be included placed in the Additional section
   (see Section 3.1).

      Editors' note: Didn't the WG decide that DS RR removes additional section.  The name server
   should include the need
      for Additional section processing DNSKEY RRset if and only if there is enough space
   in the response for KEY RRs? both the DNSKEY RRset and associated RRSIG RR(s).
   If so, this
      subsection should be deleted. there is not enough space to include these DNSKEY and RRSIG RRs,
   the name server MUST omit them and MUST NOT set the TC bit solely
   because these RRs didn't fit.

3.3 Including NXT NSEC RRs In a Response

      Editors' note: This whole section uses the phrase "query name
      exists", which is somewhat ambiguous when discussing internal
      nodes with no RRs.  We are reasonably certain that, as used here,
      the phrase only refers to names which are the owner name for least
      one RR.   Better phrasing needed.

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

   Case 1: The query name exists, QNAME has RRsets associated with it in the zone, but the
      requested RR type does not exist.

   Case 2: The query name QNAME, QTYPE, QCLASS tuple does not exist, and no
      wildcard can be expanded to answer the query.

   Case 3: The query name 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 NXT NSEC RRs is included to provide
   authenticated denial of existence.

   NXT RRs are also included in a referral response when no DS RR is
   present; in this case, the NXT RR proves that no DS RR exists for the
   delegation.  Referrals are discussed in more detail in Section 3.4.

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

   If the query name exists there are RR types associated with a given QNAME, but the
   requested RR type is not present at the name, then the NXT name server
   MUST include the NSEC RR associated with the query name MUST be
   included in the Authority section.  Any SIG(s) and any RRSIG
   RRs associated with the
   NXT RRset are also included NSEC RR in the Authority section (see Section
   3.1)
   3.1).  If space does not permit the inclusion of the NXT NSEC RR (or or its
   associate SIG RRs),
   associated RRSIG RRs, the response name server MUST be considered truncated and set the TC bit MUST be set. bit.

   Note that, since the query name exists, no wildcard expansion applies
   to this query, and a single NXT NSEC RR suffices to prove the requested
   RR type does not exist.

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

   If the query name does not exist, exist in the zone, and no wildcard
   expansion matches both the query, then query name and the Authority section of query type, the response name
   server MUST include the following NXT NSEC RRs in the Authority section,
   along with their associated RRSIG RRs:

   o  An NXT NSEC RR proving that there was no exact match for the name; and

   o  An NXT NSEC RR combination proving that there was no wildcard which
      would have matched the query.  See [I-D.ietf-dnsext-wcard-clarify]
      for further information on NSEC coverage.

   If space does not permit the inclusion of these NXT NSEC and RRSIG RRs, the response
   name server MUST be considered truncated, and set the TC bit MUST be set.  Any SIG(s)
   associated with the NXT RRsets MUST also be included in the Authority
   section (see Section 3.1).

      Editors' note: Should lack of space to include the SIGs cause the
      packet to be considered truncated?

   Appendix A provides an algorithm which computes the appropriate NXT NSEC
   RRs to prove that no wildcard matches a given query name.

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

   If the query name does not exist, but a wildcard expansion can be
   used to return a positive match to the query, then the wildcard-
   expanded name server MUST
   include the wildcard-expanded answer and any SIG RRs associated with the wildcard RR MUST
   be returned corresponding
   wildcard-expanded RRSIG RRs in the Answer section.  The Authority
   section of the response MUST include the following NXT NSEC RRs along
   with their corresponding RRSIG RRs:

   o  An NXT NSEC RR which proves that there were no exact matches for the
      QNAME and QTYPE; and

   o  An NXT NSEC RR combination which proves that there are no closer
      wildcard entries which could have been expanded to match the
      query.  See [I-D.ietf-dnsext-wcard-clarify] for further
      information on NSEC coverage.

   If space does not permit inclusion of these NXT NSEC and RRSIG RRs, the response
   name server MUST be considered truncated, and set the TC bit MUST be set.  Any SIG
   RRs associated with the NXT RRsets MUST also be included in the
   response.

      Editors' note: Should lack of space to include the SIGs cause the
      packet to be considered truncated? (see Section 3.1).

   Appendix A provides an algorithm which computes the appropriate NXT NSEC
   RRs to prove that no closer wildcard matches the query name.

3.4 Including DS RRs In a Response

   When a query has the DO bit set to one, and a DS RR exists at the
   query name, an authoritative security-aware name server returning a
   referral for the delegation MUST include both the NS RRset and also
   the DS RRset and its associated SIG RRSIG RR(s).  The name server MUST
   place the NS RRset MUST be
   placed before the DS RRset and its associated SIG RRSIG RRs.

   When a query has the DO bit set to one, and no DS RR exists at the
   query name, an authoritative security-aware name server returning a
   referral for the delegation MUST include both the NS RRset and also
   the NXT NSEC RR and associated SIG RRSIG RR(s) which proves that the DS RRset
   does not exist.  The name server MUST place the NS RRset MUST be placed before the NXT
   NSEC RRset and its associated SIG RRSIG RR(s).

   This

   Including these DS and RRSIG RRs increases the size of referral
   messages, and may cause some or all glue RRs to be omitted.  If space
   does not permit the inclusion of the DS or NXT NSEC RRset and associated SIG
   RRSIG RRs, the response name server MUST be
   considered truncated, and set the TC bit MUST be set. bit.

   Security-aware name servers also include NSEC RRs in a referral
   response when no DS RR is present; in this case, the NSEC RR proves
   that no DS RR exists for the delegation. Section 3.4 discusses
   referrals in more detail.

3.5 Responding to Queries for DS RRs

   The DS record is the first resource record type which is unusual in that it appears only on the
   parent zone's side of a zone cut.  In other words, the DS record for
   the delegation of "example.com" is only stored in the "com" zone.
   This introduces novel name server behavior, since the name server for
   the child zone is authoritative for the name by the normal DNS rules
   but the child zone does not contain the DS RR.  A  An authoritative name
   server's response to a DS query depends on whether the name server is
   authoritative for the parent zone, the child zone, or both, as
   described below.

   If a name server is authoritative for the parent zone, and receives a
   query for the DS record at the delegated name, then the name server
   MUST return the DS RRset from the parent zone.  This rule applies
   regardless of whether or not the name server is also authoritative
   for the child zone.

   If the name server is authoritative for the child zone, is not
   authoritative for the parent zone, and receives a query for the DS
   record at the delegated name, there is no obvious response, because
   the child zone is not authoritative for the DS record at the child
   zone's apex, and the authoritative DS RR is only stored at the
   parent.

   If the name server allows recursion, and the RD bit is set in the
   query, the name server MAY perform recursion to find the DS record
   for the delegated name from the parent zone, and MAY return the DS
   record from its cache.  In this case, the AA bit MUST NOT be set in
   the response.

   If the name server does not perform recursion to find the DS RR,  the
   name server MUST reply with:

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

   In other words, a name server which is authoritative for the child
   zone but not for the parent zone answers as if the DS record does not
   exist.  Note that security-aware resolvers will query the parent zone
   at delegation points, and thus will not be affected by this behavior.

   For example, suppose that "example.com" is a delegation point, and a
   name server receives a query for the "example.com" DS RRset.

   o  If the name server is authoritative for "com", the name server
      MUST reply with the "example.com" DS RRset from the "com" zone.

   o  If the name server is authoritative for "example.com", is not
      authoritative for "com", and the RD bit is set to one in the
      query, the name server MAY perform recursion to find the
      "example.com" DS record.  If the name server does not use
      recursion to obtain the DS RR, the name server MUST reply as
      though the DS RR did not exist:

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

3.6 Responding to Queries for Type AXFR or IXFR

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

   An authoritative name server is not required to verify that a zone is
   properly signed before sending or accepting a zone transfer.
   However, an authoritative name server MAY choose to reject the entire
   zone transfer if the zone fails meets any of the signing requirements
   described in Section Section 2.  The primary objective of a zone transfer is
   to ensure that all authoritative name servers have identical copies
   of the zone.  An authoritative name server which chooses to perform
   its own zone validation MUST NOT selectively reject some RRs and
   accept others.

   Note that the DS RR appears only in the parental side of a
   delegation, delegation
   and is authoritative data in the parent zone. For example, the DS RR
   for "example.com" is stored in the "com" zone (the parent zone)
   rather than in 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 NXT NSEC RRs appear in both the parent and child
   zones at a delegated name, and that the NXT NSEC RRs for the delegated
   name in the parent and child zones are never identical to each other.
   As with any other authoritative RRset, the parental NXT NSEC RR at a
   delegated name MUST be included zone transfers of the parent zone,
   while the NXT NSEC at the zone apex of the child zone MUST be included in
   zone transfers of the child zone.

3.7 Setting the AD and CD Bits in a Response

      Editors' note: This section seems a little lost here. Perhaps we
      should rearrange the section ordering slightly, or provide a
      pointer to this subsection at the beginning 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 CD bit is set in query messages by the resolver, and MUST be
   copied into the response. response by the name server.  If the CD bit is set to
   one, it indicates that the resolver is willing to perform authentication, whatever
   authentication its local policy requires, and thus that the 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 the its own local
   name server policy.  The CD bit MAY be used in constructing policy, and the local name server policy.  If MAY use the CD bit as input
   to its own local policy.  However, if the resolver has set the CD
   bit, a name server policy does perform
   authentication, any RRsets rejected by SHOULD, if possible, return the requested data to
   the resolver even if the name server's local authentication policy MUST NOT be returned
   would reject the records in a response (regardless of question.  That is, by setting the CD bit).
   bit, the resolver has taken responsibility for performing its own
   authentication, and the name server should not interfere in this
   case.

   The AD bit is set by name servers, and indicates the data in the
   response has been authenticated by the name server, according to the
   local name server policy.  The AD bit MUST NOT be set on a response
   unless all of the RRsets in the Answer and Authority sections have
   met the name server's local authentication policy.  A resolver MUST
   NOT trust the AD bit unless it communicates with the name server over
   a secure transport mechanism and is explicitly configured to trust
   the name server's policy.

3.8 Example DNSSEC Responses

      Editors' note: these examples probably ought to move to an
      appendix 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 the formation of replies by an authoritative name server.
   The zone has two name servers, a single child, and a wildcard MX RR.
   The zone is completely signed and has a full NXT NSEC chain.

      example.com.    SOA     (...)
                      SIG
                      RRSIG     SOA ...
                      NS      a.example.com.
                      NS      b.example.com.
                      SIG
                      RRSIG     NS ...
                      MX      10 a.example.com
                      SIG
                      RRSIG     MX ...
                      KEY
                      DNSKEY     ...
                      SIG     KEY
                      RRSIG     DNSKEY ...
                      NXT
                      NSEC     *.example.com.
      *               MX      10 a.example.com.
                      SIG
                      RRSIG     MX ...
                      NXT
                      NSEC     a.example.com.
      a               A       10.10.10.1
                      SIG
                      RRSIG     A ...
                      NXT
                      NSEC     b.example.com.
      b               A       10.10.10.2
                      SIG
                      RRSIG     A ...
                      NXT
                      NSEC     c.example.com.
      c               CNAME   a.example.com.
                      SIG

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

   A query to the authoritative name server 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 SIG RRSIG CNAME
         a.example.com.         IN A   10.10.10.1
                                IN SIG RRSIG A
      AUTHORITY:
         example.com.           IN NS  a.example.com.
                                IN NS  b.example.com.
                                IN SIG RRSIG NS ...
      ADDITIONAL:
         a.example.com.         IN A   10.10.10.1
                                IN SIG RRSIG A ...
         b.example.com.         IN A   10.10.10.2
                                IN SIG RRSIG A ...
         example.com.           IN KEY ...
                                IN SIG KEY ...

   A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
   results in a referral to a signed zone.  The resolver can determine
   that "sub.example.com" is signed because of the presence of the DS RR
   with the hash 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  SIG  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 in a referral to an unsigned zone. The resolver knows
   not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS
   bit in the NXT NSEC RR bitmap in the referral is not set.  Even if DNSSEC
   RRs are present in responses from "sub-nosig.example.com" name
   servers, the resolver will not be able to construct a authentication
   chain, since there is a break between "sub-nosig.example.com" 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  NXT  NSEC ;; (DS bit not set)
                                     IN  SIG NXT  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 a name
   error, because the name does not exist and is not covered by wildcard
   expansion.  Therefore, the name server must present proof that the
   name does not exist, and that no wildcard expansion is present which
   could have been used 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  SIG  RRSIG SOA ...
         c.example.com.        IN  NXT  NSEC sub.example.com. ...
                               IN  SIG NXT  RRSIG NSEC ...
         *.example.com.        IN  NXT  NSEC a.example.com. ...
                               IN  SIG NXT  RRSIG NSEC ...
      ADDITIONAL:
         example.com.          IN  KEY  DNSKEY ...
                               IN  SIG KEY  RRSIG DNSKEY ...

   A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
   RR synthesized via wildcard expansion.  The name server must prove
   that 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  SIG  RRSIG MX ...
      AUTHORITY:
         example.com.          IN  NS  a.example.com.
                               IN  NS  b.example.com.
                               IN  SIG  RRSIG NS ...
         c.example.com.        IN  NXT  NSEC sub.example.com.
                               IN  SIG NXT  RRSIG NSEC ...
      ADDITIONAL:
         a.example.com.        IN  A   10.10.10.1
                               IN  SIG  RRSIG A ...
         b.example.com.        IN  A   10.10.10.2
                               IN  SIG  RRSIG A ...
         example.com.          IN  KEY ...
                               IN  SIG KEY ...

   If these responses came from a recursive name server which had all of
   the necessary RRsets in its cache instead of from an authoritative
   server, the only differences would be the TTLs and the header flags.
   The AA bit would not be set, and the AD bit would be set if (and only
   if) all the RRsets in a response passed the security policy checks of
   the recursive name server.

4. Resolving

      Editors' note: This section is still very rough, and some of the
      text here duplicates text from other portions of this document.
      This needs to be fixed (one way or another) during final editing.
      Suggestions for better text would be welcome.

   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 a
   separate subsection.

   A security-aware resolver MUST include an EDNS [6] [RFC2671] OPT
   pseudo-RR with the DO [7] [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 EDNS OPT pseudo-RR. A security-aware resolver MUST
   handle fragmented UDP packets correctly regardless of whether any
   such fragmented packets were received via IPv4 or IPv6.  Please see [8]
   [RFC3226] for discussion of these requirements.

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

   o  The security-aware resolver is part of a security-aware recursive
      name server, and the response is the result of recursion on behalf
      of a query received with the CD bit set;

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

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

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

   A security-aware resolver MUST attempt to retrieve missing DS, KEY,
   DNSKEY, or SIG RRSIG RRs via explicit queries if the resolver needs these
   RRs in order to perform signature verification.

   A security-aware resolver MUST attempt to retrieve missing a NXT NSEC RR
   which the resolver needs to authenticate a NODATA response.  In
   general it is not possible for a resolver to retrieve missing NXT NSEC
   RRs, since the resolver will have no way of knowing the owner name of
   the missing NXT NSEC RR, but in the specific case of a NODATA response,
   the resolver does know the name of the missing NXT NSEC RR, and must
   therefore attempt to retrieve it.

   A security-aware resolver MUST be able to determine whether or not it
   should expect a 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 chain of
       signed KEY DNSKEY and DS RRs from a trusted starting point to the
       RRset.  In this case, the RRset should be signed, and is subject
       to signature validation as described above.

   2.  An RRset for which the resolver knows that it has no chain of
       signed KEY DNSKEY and DS RRs from any trusted starting point to the
       RRset.  This can occur when the target RRset lies in an unsigned
       zone or in a descendent of an unsigned zone.  In this case, the
       RRset may or may not be signed, but the resolver will not be able
       to verify the signature.

   3.  An RRset for which the resolver is not able to determine whether
       or not the RRset should be signed, because the resolver is not
       able to obtain the necessary DNSSEC RRs. This can occur due when the
       security-aware resolver is not able to contact security-aware
       name servers for the relevant zones.

   A security-aware resolver MUST be capable of being preconfigured with
   at least one trusted public key, and SHOULD MUST be capable of being
   preconfigured with multiple trusted public keys. keys or DS RRs. Since a security-
   aware
   security-aware resolver will not be able to validate signatures
   without such a preconfigured trusted key, the resolver SHOULD have
   some reasonably robust mechanism for obtaining such keys when it
   boots.

      Editors' note: Should support for multiple public keys be a MUST
      rather than a SHOULD?

   A security-aware resolver SHOULD cache each response 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 resolver SHOULD discard the
   entire atomic entry when any of the RRs contained in it expire.

      Editors' note: This is implementation advice which came out of
      discussions at various workshops and investigations into possible
      implementation issues

   A security-aware resolver SHOULD NOT cache data with invalid
   signatures under normal circumstances.  However, a security-aware
   resolver SHOULD take steps to rate limit the (as yet unsettled) opt-in proposal.

      All number of this advice has been discussed in WG meetings, and as far
      as the editors know these recommendations are not controversial,
      but identical
   queries it is up to generates, which may require the WG resolver to decide whether retain some
   data about recently generated queries. Conceptually, this sort is similar
   to negative caching [RFC2308], but since the resolver has no way of
      implementation advice belongs
   obtaining the appropriate caching TTL from received data in this document.
   case, the TTL will have to be set by the implementation.  This
   document refers data retained as part of such a rate limiting
   mechanism as the "BAD cache".

4.1 Recursive Name Servers

   As explained in [9], [I-D.ietf-dnsext-dnssec-intro], a security-aware
   recursive name server is an entity which acts in both the
   security-aware name server and security-aware resolver roles. This
   section uses the terms "name server side" and "resolver side" to
   refer to the code within a security-aware recursive name server which
   implements the security-
   aware security-aware name server role and the code which
   implements the security-
   aware security-aware resolver role, respectively.

   The resolver side of a

   A security-aware recursive name server MUST set
   the DO bit when sending requests, regardless of the state of the DO
   bit in the initiating request received by the name server side.  If
   the initiating request does not have the DO bit set, the name server
   side MUST remove any DNSSEC RRs from the response sent to the
   initiating resolver, but the resolver side MUST follow the usual
   rules for caching which would apply to any security-aware resolver.

   A security-aware recursive name server SHOULD NOT attempt to answer a
   query NOT attempt to 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 SHOULD MUST NOT use NXT NSEC
   RRs from one negative response to synthesize a response for a
   different query.  A security-aware recursive name server SHOULD MUST NOT use
   a previous wildcard expansion to generate a response to a different
   query.

      Editors' note: Should any of the SHOULD NOTs in this paragraph be
      MUST NOTs instead?

   The name server side of a security-aware recursive name server MUST
   pass the sense of the CD bit to the resolver side along with the rest
   of an initiating query, so that the resolver side will know whether
   whether or not it is required to verify the response data it returns
   to the name server side.

      Editors' note: What should

   The resolver side of a security-aware recursive name server
      do if it receives a query with CD=1 and DO=0?

4.2 Stub resolvers

   A security-aware stub resolver MUST include an EDNS [6] OPT pseudo-RR
   with set
   the DO [7] bit set to one when sending queries.

   A security-aware stub resolver MUST support a message size of at
   least 1220 octets, SHOULD support a message size requests, regardless of 4000 octets, and
   MUST advertise the supported message size using state of the "sender's UDP
   payload size" field DO
   bit in the EDNS OPT pseudo-RR.  A security-aware stub
   resolver MUST handle fragmented UDP packets correctly regardless of
   whether any such fragmented packets were initiating request received via IPv4 or IPv6.
   Please see [8] for discussion of these requirements.

   A security-aware stub resolver MUST support by the DNSSEC RR types, at
   least to name server side.  If
   the extent of DO bit in an initiating query is not mishandling responses just because they
   contain DNSSEC RRs.   A security-aware stub resolver MAY include set, the
   DNSSEC RRs returned by a security-aware recursive name server as part
   of side
   MUST strip any authenticating DNSSEC RRs from the data response, but but
   MUST NOT strip any DNSSEC RRs that it the stub initiating query explicitly
   requested.

   The resolver hands back to side MUST follow the application
   which invoked it, but is not required usual rules for caching and
   negative caching which would apply to do so.

   A any security-aware stub resolver.

   If the name server side receives a query which matches an entry in
   the resolver side's BAD cache, the name server side's response
   depends on the setting of the CD bit in the original query.  If the
   CD bit is set, the name server side SHOULD NOT set return the data from the
   BAD cache; if the CD bit when sending
   queries, since, by definition, a security-aware stub resolver does is not validate signatures and thus depends on set, the name server side SHOULD
   return RCODE 2 (server failure).

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer or Authority sections of the response to perform validation on its behalf.

      Editors' note: Should this be
   authentic, and SHOULD NOT set the AD bit if and only if the name server
   considers all RRsets in the Answer section and any relevant negative
   response RRs in the Authority section to be authentic.  How the name
   server side of a MUST NOT?

   A security-aware stub resolver MUST NOT place any reliance on
   signature validation allegedly performed recursive name server determines
   whether an RRset is authentic depends on its behalf except when the security-aware stub origin of the RRset.  If
   the RRset came from the resolver obtained side of the data recursive name server
   (the normal case), recursive name server MUST follow the procedure
   described in question Section 5.  If the RRset came from a
   trusted security-aware zone for which the
   name server side of the recursive name server via a secure channel.

5. Authenticating DNS Responses

   In order to use DNSSEC RRs for authentication, a security-aware
   resolver requires preconfigured knowledge of at least one
   authenticated KEY RR.  The process for obtaining and authenticating
   this initial KEY RR is achieved via some external mechanism.  For
   example, a resolver could use some off-line authenticated exchange to
   obtain a zone's KEY RR or obtain a DS RR that identifies and
   authenticates a zone's KEY RR.  The remainder of this section assumes
   that authoritative, local
   policy MAY consider the resolver has somehow obtained an initial set of
   authenticated KEY RRs.

   An initial KEY RR can be used RRset to authenticate a zone's apex KEY
   RRset.  To authenticate an apex KEY be authentic without further
   verification simply because the RRset using came from an initial key, authoritative
   zone, but the
   resolver MUST:

   1.  Verify that name server SHOULD NOT do so unless the initial KEY RR appears in it obtained the apex KEY RRset,
   authoritative zone via secure means (such as a secure zone transfer
   mechanism), and
       verify that the KEY RR MUST NOT do so unless this behavior has been
   configured explicitly.

4.2 Stub resolvers

   A security-aware stub resolver MUST include an EDNS [RFC2671] OPT
   pseudo-RR with the Zone Key Flag (KEY RDATA DO [RFC3225] bit 7) set to one.

   2.  Verify that there is some SIG RR which covers the apex KEY RRset,
       and that the combination one when sending queries.

   A security-aware stub resolver MUST support a message size of the SIG RR at
   least 1220 octets, SHOULD support a message size of 4000 octets, and
   MUST advertise the initial KEY RR
       authenticates the KEY RRset.  The process for supported message size using a SIG RR to
       authenticate an RRset is described the "sender's UDP
   payload size" field in Section 5.2.

   Once the EDNS OPT pseudo-RR. A security-aware stub
   resolver has authenticated the apex KEY RRset using an
   initial KEY RR, delegations from that zone can be authenticated using
   DS RRs.  This allows a MUST 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 stub resolver to start from an initial key, and use
   DS RRsets to proceed recursively down the DNS tree obtaining other
   apex KEY RRsets.  If MUST support the resolver were preconfigured with a root KEY
   RR, and if every delegation had a DS DNSSEC RR associated with it, then the
   resolver could obtain any apex KEY RRset.  The process of using DS
   RRs types, at
   least to authenticate referrals is described in Section 5.1.

   Once the resolver has authenticated a zone's apex KEY RRset, Section
   5.2 shows how the extent of not mishandling responses just because they
   contain DNSSEC RRs.   A security-aware stub resolver can use KEY RRs in MAY include the apex KEY RRset and
   SIG
   DNSSEC RRs from the zone to authenticate any other RRsets in returned by a security-aware recursive name server as part
   of the zone.
   Section 5.3 shows how data that it the stub resolver can use authenticated NXT RRsets
   from the zone hands back to prove that an RRset the application
   which invoked it but is not present in required to do so.

   A security-aware stub resolver SHOULD NOT set the zone.

   When CD bit when sending
   queries, since, by definition, a security-aware stub resolver indicates support for DNSSEC, a does
   not validate signatures and thus depends on the security-aware
   recursive name server should attempt to provide the necessary KEY, SIG, NXT, and DS
   RRsets in a response (see Section 3).  However, a perform validation on its behalf.

   A security-aware stub resolver may still receive a MAY chose to examine the setting of
   the AD bit in response which messages that lacks the
   appropriate DNSSEC RRs, whether due it receives in order to configuration issues such as a
   security-oblivious
   determine whether the security-aware recursive name server which accidently 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 that DNSSEC RRs appear not sent
   the response claims to be requested.  The absence of
   DNSSEC have cryptographically verified the data in a response MUST NOT by itself be taken as an
   indication that no authentication information exists.

   A resolver SHOULD expect authentication information from signed
   zones.  A resolver SHOULD believe that a zone is signed if the
   resolver has been configured with public key information for the
   zone, or if
   the zone's parent is signed Answer and Authority sections of the delegation from response message.  Note,
   however, that the
   parent contains responses received by a DS RRset.

5.1 Authenticating Referrals

   Once security-aware stub
   resolver are heavily dependent on the apex KEY RRset for local policy of the
   security-aware recursive name server, so as a signed parent zone has been
   authenticated, DS RRsets can practical matter there
   may be used to authenticate the delegation little practical value to a signed child zone.  A DS RR identifies a KEY RR in checking the child
   zone's apex KEY RRset, and contains a cryptographic digest status of the
   child zone's KEY RR.  A strong cryptographic digest algorithm ensures
   that an adversary can not easily generate AD bit
   except perhaps as a KEY RR that matches the
   digest.  Thus, authenticating the digest allows debugging aid.  In any case, a security-aware
   stub resolver to
   authenticate the matching KEY RR.  The MUST NOT place any reliance on signature validation
   allegedly performed on its behalf except when the security-aware stub
   resolver can then use this
   child KEY RR to authenticate obtained the entire child apex KEY RRset.

   Given data in question from a DS RR trusted security-aware
   recursive name server via a secure channel.

5. Authenticating DNS Responses

   In order to use DNSSEC RRs for authentication, a delegation, the child zone's apex KEY RRset can
   be authenticated if all security-aware
   resolver requires preconfigured knowledge of the following hold:

   o at least one
   authenticated DNSKEY or DS RR.  The process for obtaining and
   authenticating this initial DNSKEY or DS RR has been authenticated using is achieved via some
   external mechanism.  For example, a resolver could use some KEY off-line
   authenticated exchange to obtain a zone's DNSKEY RR in the parent's
      apex KEY RRset (see Section 5.2);

   o  The Algorithm and Key Tag in the or obtain a DS RR match the Algorithm field
   that identifies and authenticates a zone's DNSKEY RR.  The remainder
   of this section assumes that the key tag resolver has somehow obtained an
   initial set of a KEY authenticated DNSKEY RRs.

   An initial DNSKEY RR in the child can be used to authenticate a zone's apex KEY DNSKEY
   RRset.  To authenticate an apex DNSKEY RRset
      which, when hashed using an initial key,
   the digest algorithm specified in resolver MUST:

   1.  Verify that the DS
      RR's Digest Type field, results initial DNSKEY RR appears in a digest value which matches the Digest field of the DS RR; apex DNSKEY
       RRset, and

   o  The matching KEY RR in verify that the child zone DNSKEY RR has the Zone Key Flag
       (DNSKEY RDATA bit 7) set to
      one, the corresponding private key has signed one.

   2.  Verify that there is some RRSIG RR which covers the child zone's apex KEY DNSKEY
       RRset, and that the resulting SIG combination of the RRSIG RR authenticates and the child
      zone's apex KEY initial
       DNSKEY RR authenticates the DNSKEY RRset.

   If  The process for using
       an RRSIG RR to authenticate an RRset is described in Section 5.3.

   Once the referral from resolver has authenticated the parent apex DNSKEY RRset using an
   initial DNSKEY RR, delegations from that zone did not contain a can be authenticated
   using DS RRset, the
   response should have included RRs.  This allows a signed NXT RRset proving that no resolver to start from an initial key,
   and use DS
   RRset exists for RRsets to proceed recursively down the delegated name (see Section 3.4).  A security-
   aware resolver MUST send DNS tree obtaining
   other apex DNSKEY RRsets.  If the parent resolver were preconfigured with a query for the DS RRset
   root DNSKEY RR, and if the
   referral includes neither every delegation had a DS RRset nor a NXT RRset proving RR associated with
   it, then the
   nonexistence resolver could obtain and validate any apex DNSKEY
   RRset.  The process of the using DS RRset (see RRs to authenticate referrals is
   described in Section 4).

   If 5.2.

   Once the resolver authenticates an NXT RRset which proves that no DS has authenticated a zone's apex DNSKEY RRset,
   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
   DNSKEY RRset is present for this zone, then there is no authentication path
   leading and RRSIG RRs from the parent zone to authenticate any other
   RRsets in the child.  If zone.  Section 5.4 shows how the resolver has an initial
   KEY RR which belongs to can use
   authenticated NSEC RRsets from the child zone or to any delegation below the
   child zone, this initial KEY RR MAY be used to re-establish prove that an
   authentication path.  If no such initial KEY RR exists, the resolver
   can RRset is not authenticate RRsets at or below
   present in the child zone.

   Note that, for a signed delegation, there are two NXT RRs associated
   with the delegated name.  One NXT RR resides in the parent zone, and
   can be used to prove whether

   When a DS RRset exists resolver indicates support for DNSSEC, a security-aware name
   server should attempt to provide the delegated
   name.  The second NXT RR resides in the child zone, necessary DNSKEY, RRSIG, NSEC,
   and identifies
   which DS RRsets are present at the apex of the child zone.  The parent
   NXT RR and child NXT RR can always be distinguished, since the SOA
   bit will be set in the child NXT RR and clear in the parent NXT RR.
   A a response (see Section 3).  However, a
   security-aware resolver MUST use may still receive a response which that lacks
   the parent NXT RR when attempting appropriate DNSSEC RRs, whether due to prove that configuration issues such
   as a DS RRset does not exist.

5.2 Authenticating security-oblivious recursive name server which accidentally
   interfere with DNSSEC RRs or due to a deliberate attack in which an RRSet Using
   adversary forges a SIG RR

   A resolver can use response, strips DNSSEC RRs from a SIG RR and its corresponding KEY RR to attempt response, or
   modifies a query so that DNSSEC RRs appear not to authenticate RRsets. be requested.  The
   absence of DNSSEC data in a response MUST NOT by itself be taken as
   an indication that no authentication information exists.

   A resolver first checks the SIG RR to
   verify SHOULD expect authentication information from signed
   zones. A resolver SHOULD believe that it covers the RRset, has a valid time interval, and
   identifies a valid KEY RR.  The resolver then constructs the
   canonical form of the zone is signed data by appending the SIG RDATA
   (excluding if the Signature Field) with the canonical form of the
   covered RRset.  Finally,
   resolver uses the has been configured with public key and signature
   to authenticate information for the
   zone, or if the zone's parent is signed data.  Section 5.2.1, Section 5.2.2, and
   Section 5.2.3 describe each step in detail.

5.2.1 Checking the SIG RR Validity

   A security-aware resolver can use delegation from the
   parent contains a SIG RR DS RRset.

5.1 Special Considerations for Islands of Security

   Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
   zones for which it is not possible to authenticate construct an RRset
   if all of authentication
   chain to the following conditions hold:

   o  The SIG RR and zone from its parent.  Validating signatures within an
   island of security requires the RRset MUST validator to have the same owner name and the
      same class;

   o  The SIG RR's Signer's Name field MUST be the name some other means of the
   obtaining a trusted zone that
      contains key.  If a validator cannot obtain such a
   key, it will have to choose whether to accept the RRset;

   o  The SIG RR's Type Covered field MUST equal unvalidated
   responses or not based on local policy.

   All the RRset's type;

   o normal processes for validating responses apply to islands of
   security.  The number only difference between normal validation and
   validation within an island of labels security is in how the validator
   obtains a trusted starting point for the authentication chain.

5.2 Authenticating Referrals

   Once the apex DNSKEY RRset owner name MUST for a signed parent zone has been
   authenticated, DS RRsets can be greater than
      or equal used to authenticate the value delegation
   to a signed child zone.  A DS RR identifies a DNSKEY RR in the SIG RR's Labels field;

   o  The resolver's notion child
   zone's apex DNSKEY RRset, and contains a cryptographic digest of the current time MUST be less than or
      equal to the time listed in
   child zone's DNSKEY RR.  A strong cryptographic digest algorithm
   ensures that an adversary can not easily generate a DNSKEY RR that
   matches the SIG RR's Expiration field;

   o digest.  Thus, authenticating the digest allows a
   resolver to authenticate the matching DNSKEY RR.  The resolver's notion of resolver can
   then use this child DNSKEY RR to authenticate the current time MUST entire child apex
   DNSKEY RRset.

   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
   can be greater than or
      equal to authenticated if all of the time listed following hold:

   o  The DS RR has been authenticated using some DNSKEY RR in the SIG RR's Inception field;
      parent's apex DNSKEY RRset (see Section 5.3);

   o  The SIG RR's Signer's Name, Algorithm, Algorithm and Key Tag fields MUST in the DS RR match the owner name, algorithm, Algorithm field
      and the key tag for some KEY of a DNSKEY RR in the child zone's apex KEY RRset; DNSKEY
      RRset which, when hashed using the digest algorithm specified in
      the DS RR's Digest Type field, results in a digest value which
      matches the Digest field of the DS RR; and

   o  The matching KEY DNSKEY RR MUST be present in the zone's apex KEY RRset,
      and MUST have child zone has the Zone Flag bit (KEY RDATA Flag bit 7) set
      to one.

   It is possible for more than one KEY RR to match one, the conditions
   above.  In this case, corresponding private key has signed the resolver can not predetermine which KEY RR
   to use to authenticate child zone's
      apex DNSKEY RRset, and the signature, MUST try each matching KEY resulting RRSIG RR
   until authenticates the resolver has either validated
      child zone's apex DNSKEY RRset.

   If the signature or has run out
   of matching keys to try.

   Note that this authentication process is only meaningful if referral from the
   resolver authenticates parent zone did not contain a DS RRset, the KEY RR before using it to validate
   signatures.  The matching KEY RR is considered to be authentic if:

   o  The apex KEY
   response should have included a signed NSEC RRset containing proving that no DS
   RRset exists for the KEY RR is considered authentic;
      or

   o  The delegated name (see Section 3.4).  A
   security-aware resolver MUST query the name servers for the parent
   zone for the DS RRset covered by if the SIG RR is referral includes neither a DS RRset nor
   a NSEC RRset proving that the apex KEY DS RRset itself, and does not exist (see Section
   4).

   If the KEY RR either matches resolver authenticates an authenticated NSEC RRset which proves that no DS RR
   RRset is present for this zone, then there is no authentication path
   leading from the parent to the child.  If the resolver has an initial
   DNSKEY or DS RR which belongs to the child zone or matches a to any delegation
   below the child zone, this initial DNSKEY or DS RR MAY be used to
   re-establish an authentication path.  If no such initial DNSKEY or KEY DS
   RR which exists, the resolver has been
      preconfigured to believe to be authentic.

5.2.2 Reconstructing can not authenticate RRsets in or below the Signed Data

   Once
   child zone.

   Note that, for a signed delegation, there are two NSEC RRs associated
   with the SIG delegated name.  One NSEC RR has met the validity requirements described resides in
   Section 5.2.1, the resolver needs parent zone, and
   can be used to reconstruct prove whether a DS RRset exists for the original signed
   data. delegated
   name.  The original signed data includes SIG RDATA (excluding second NSEC RR resides in the
   Signature field) child zone, and identifies
   which RRsets are present at the canonical form of the RRset.  Aside from
   being ordered, the canonical form apex of the RRset might also differ from child zone.  The parent
   NSEC RR and child NSEC RR can always be distinguished, since the received SOA
   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
   A security-aware resolver MUST use the parent NSEC RR when attempting
   to prove that a DS RRset due does not exist.

5.3 Authenticating an RRset Using an RRSIG RR

   A resolver can use an RRSIG RR and its corresponding DNSKEY RR to DNS name compression, decremented TTLs, or
   wildcard expansion.
   attempt to authenticate RRsets.  The resolver should use first checks the following RRSIG
   RR to
   reconstruct verify that it covers the original signed data:

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

            "|" denotes concatenation

            SIG_RDATA is RRset, has a valid time interval, and
   identifies a valid DNSKEY RR.  The resolver then constructs the wire format
   canonical form of the SIG signed data by appending the RRSIG RDATA fields with
   (excluding the Signature field excluded and Field) with the Signer's Name in canonical form.

            RR(i) = name | class | type | OrigTTL | RDATA length | RDATA
               name is calculated according to form of the function below

               class is
   covered RRset.  Finally, resolver uses the RRset's class

               type is public key and signature
   to authenticate the RRset type signed data.  Section 5.3.1, Section 5.3.2, and all RRs
   Section 5.3.3 describe each step in detail.

5.3.1 Checking the class

               OrigTTL is RRSIG RR Validity

   A security-aware resolver can use an RRSIG RR to authenticate an
   RRset if all of the value from following conditions hold:

   o  The RRSIG RR and the SIG Original TTL field

               All names in RRset MUST have the RDATA field are in canonical form same owner name and the
      same class;

   o  The set RRSIG RR's Signer's Name field MUST be the name of all RR(i) is sorted into canonical order.

            To calculate the name:
               let sig_labels = the value of zone
      that contains the SIG Labels RRset;

   o  The RRSIG RR's Type Covered field

               let fqdn = MUST equal the RRset's fully qualified domain name type;

   o  The number of labels in
                               canonical form

               let fqdn_labels = RRset's fully qualified domain the RRset owner name MUST be greater than
      or equal to the value in
                               canonical form

               if sig_labels = fqdn_labels,
                   name = fqdn

               if sig_labels < fqdn_labels,
                  name = "*." | the leftmost sig_label labels RRSIG RR's Labels field;

   o  The resolver's notion of the
   	                     fqdn

               if sig_labels > fqdn
                  the SIG RR did not pass the necessary validation
                  checks and current time MUST NOT be used less than or
      equal to authenticate this
                  RRset.

      Editors' note: the time listed in the RRSIG RR's Expiration field;

   o  The algorithm above needs to resolver's notion of the current time MUST be cross-checked very
      carefully against greater than or
      equal to the definitions time listed in [10].

   Section 5.4.1 gives an example of original name calculation. the RRSIG RR's Inception field;

   o  The
   canonical forms for names RRSIG RR's Signer's Name, Algorithm, and RRsets are defined in [10].

   NXT RRsets at a delegation boundary require special processing.
   There are two distinct NXT RRsets associated with a signed delegated
   name.  One NXT RRset resides in Key Tag fields MUST
      match the parent zone, owner name, algorithm, and specifies which
   RRset are present at key tag for some DNSKEY RR in
      the parent zone. zone's apex DNSKEY RRset;

   o  The second NXT RRset resides
   at the child zone, and identifies which RRsets are matching DNSKEY RR MUST be present at the
   apex in the child zone.  The parent NXT RRset zone's apex DNSKEY
      RRset, and child NXT RRset can
   always be distinguished since only MUST have the child NXT RRs will specify an
   SOA RRset exists at the name.  When reconstructing the original NXT
   RRset Zone Flag bit (DNSKEY RDATA Flag bit 7)
      set to one.

   It is possible for more than one DNSKEY RR to match the delegation from conditions
   above.  In this case, the parent zone, resolver can not predetermine which DNSKEY
   RR to use to authenticate the NXT RRs signature, MUST NOT
   be combined with NXT RRs from the child zone, and when reconstructing try each matching
   DNSKEY RR until the original NXT RRset for resolver has either validated the apex signature or
   has run out of matching keys to try.

   Note that this authentication process is only meaningful if the child zone,
   resolver authenticates the NXT RRs
   MUST NOT DNSKEY RR before using it to validate
   signatures.  The matching DNSKEY RR is considered to be combined with NXT RRs from authentic if:

   o  The apex DNSKEY RRset containing the parent zone.

   Note also that each of DNSKEY RR is considered
      authentic; or

   o  The RRset covered by the two NXT RRsets at a delegation point has a
   corresponding SIG RRSIG RR with an owner name matching is the delegated name, apex DNSKEY RRset itself,
      and each of these SIG RRs is authoritative data associated with the
   same DNSKEY RR either matches an authenticated DS RR from the
      parent zone or matches a DS RR or DNSKEY RR which contains the corresponding NXT RRset.  If necessary,
   a resolver can tell these SIG RRs apart by checking the Signer's Name
   field.

5.2.3 Checking has
      been preconfigured to believe to be authentic.

5.3.2 Reconstructing the Signature Signed Data

   Once the resolver RRSIG RR has validated met the SIG RR as validity requirements described in
   Section
   5.2.1 and reconstructed 5.3.1, the resolver needs to reconstruct the original signed
   data.  The original signed data as described in
   Section 5.2.2, includes RRSIG RDATA (excluding the resolver can attempt to use
   Signature field) and the cryptographic
   signature to authenticate the signed data, and thus (finally!)
   authenticate canonical form of the RRset.

   The Algorithm field in  Aside from
   being ordered, the SIG RR identifies canonical form of the cryptographic
   algorithm to generate RRset might also differ from
   the signature. received RRset due to DNS name compression, decremented TTLs, or
   wildcard expansion.  The signature itself resolver should use the following to
   reconstruct the original signed data:

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

            "|" denotes concatenation

            RRSIG_RDATA is
   contained in the Signature field wire format of the SIG RDATA, RRSIG RDATA fields
               with the Signature field excluded and the public key Signer's Name
               in canonical form.

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

               name is calculated according to used generate the signature function below

               class is contained in the Public Key field
   of RRset's class

               type is the matching KEY RR(s) (found in Section 5.2.1).  [10] provides a
   list of algorithm types, RRset type and provides pointers to all RRs in the documents that
   define each algorithm's use.

   Note that it class

               OrigTTL is possible for more than one KEY RR to match the
   conditions in Section 5.2.1.  In this case, the resolver can only
   determine which KEY RR by trying each matching key until value from the resolver
   either succeeds RRSIG Original TTL field

               All names in validating the signature or runs out of keys to
   try.

   If the Labels RDATA field are in canonical form

               The set of the SIG RR all RR(i) is not equal to sorted into canonical order.

            To calculate the number name:
               let rrsig_labels = the value of
   labels in the RRSIG Labels field

               let fqdn = 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.2.4 describes how
   to determine whether a wildcard was applied properly.

   If other SIG RRs also cover this SIG RR, the local resolver security
   policy determines whether the resolver also needs to test these SIG
   RRs, and determines how to resolve conflicts domain name in
                               canonical form

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

               if these SIG RRs lead to
   differing results.

   If the resolver accepts the RRset as authentic, rrsig_labels = fqdn_labels,
                   name = fqdn

               if rrsig_labels < fqdn_labels,
                  name = "*." | the resolver MUST set leftmost rrsig_label labels of the SIG RR's TTL and
                                fqdn
               if rrsig_labels > fqdn
                  the TTL of each RRSIG RR in did not pass the authenticated RRset necessary validation
                  checks and MUST NOT be used to
   the minimum of:

   o authenticate this
                  RRset.

   Section 5.5.1 gives an example of original name calculation.  The RRset's TTL as received
   canonical forms for names and RRsets are defined in the response;

   o  The SIG RR's TTL as received
   [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 NSEC RRset resides in the response; parent zone, and

   o  The value in specifies which
   RRset are present at the SIG RR's Original TTL field.

5.2.4 Authenticating A Wildcard Expanded parent zone.  The second NSEC RRset Positive Response

   If resides
   at the number of labels in an RRset's fully qualified domain name is
   greater than child zone, and identifies which RRsets are present at the Labels field
   apex in the covering SIG RDATA, then the child zone.  The parent NSEC RRset and its covering SIG RR were created as a result of wildcard
   expansion.  Once the resolver has verified child NSEC RRset
   can always be distinguished since only the signature as described
   in Section 5.2, child NSEC RRs will
   specify an SOA RRset exists at the resolver must take additional steps to verify name. When reconstructing the
   non-existence of an exact match or closer wildcard match
   original NSEC RRset for the
   query.   Section 5.3 discusses these steps.

   Note that delegation from the response received by parent zone, the resolver should include all
   NXT NSEC
   RRs needed to authenticate the response (see Section 3.3).

5.3 Authenticated Denial of Existence

   A resolver can use authenticated NXT MUST NOT be combined with NSEC RRs to prove that an from the child zone, and when
   reconstructing the original NSEC RRset is
   not present in a signed zone.  Security-aware name servers should
   automatically include any necessary NXT RRs for signed zones in their
   responses to security-aware resolvers.

   Security-aware resolvers MUST first authenticate NXT RRsets according
   to the standard RRset authentication rules described in Section 5.2,
   then apply apex of the NXT RRsets as follows:

   o  If child
   zone, the requested RR name matches NSEC RRs MUST NOT be combined with NSEC RRs from the owner name parent
   zone.

   Note also that each of an
      authenticated NXT RR, then the NXT RR's type bit map field lists
      all RR types present two NSEC RRsets at that a delegation point has
   a corresponding RRSIG RR with an owner name matching the delegated
   name, and each of these RRSIG RRs is authoritative data associated
   with the same zone which contains the corresponding NSEC RRset.  If
   necessary, a resolver can prove
      that the requested RR type does not exist tell these RRSIG RRs apart by checking for the RR
      type in
   Signer's Name field.

5.3.3 Checking the bit map.  Since Signature

   Once the existence of resolver has validated the authenticated NXT RRSIG RR proves that the owner name exists as described in Section
   5.3.1 and reconstructed the zone, wildcard
      expansion could not have been used original signed data as described in
   Section 5.3.2, the resolver can attempt to match use the requested RR owner
      name and type.

   o  If cryptographic
   signature to authenticate the requested RR name would appear after an authenticated NXT
      RR owner name signed data, and before thus (finally!)
   authenticate the name listed in that NXT RR's Next
      Domain Name RRset.

   The Algorithm field according to the canonical DNS name order
      defined in [10], then no exact match for the requested RRSIG RR name
      exists in identifies the zone.  However, it is possible that a wildcard could
      be used cryptographic
   algorithm to match generate the requested RR owner name signature.  The signature itself is
   contained in the Signature field of the RRSIG RDATA, and type, so proving
      that the requested RRset does not exist also requires proving that
      no possible wildcard exists which could have been used public
   key to used generate
      a positive response.

   To prove non-existence the signature is contained in the Public Key
   field of an RRset, the resolver must be able matching DNSKEY RR(s) (found in Section 5.3.1).
   [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
   and provides pointers to
   verify both that the queried RRset does not exist and documents that no
   relevant wildcard RRset exists.  Proving this may require define each algorithm's
   use.

   Note that it is possible for more than one NXT RRset from DNSKEY RR to match the zone.
   conditions 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 in validating the signature or runs out of
   keys to try.

   If the complete set Labels field of necessary NXT
   RRsets the RRSIG RR is not present in a response (perhaps due equal to truncation), the number of
   labels in the RRset's fully qualified owner name, then
   a security-aware the RRset is
   either invalid or the result of wildcard expansion.  The resolver
   MUST resend verify that wildcard expansion was applied properly before
   considering the query in order RRset to attempt be authentic.  Section 5.3.4 describes how
   to obtain determine whether a wildcard was applied properly.

   If other RRSIG RRs also cover this RRSIG RR, the full collection of NXT local resolver
   security policy determines whether the resolver also needs to test
   these RRSIG RRs, and determines how to resolve conflicts if these
   RRSIG RRs necessary lead to verify non-
   existence of differing results.

   If the requested RRset.   As with all DNS operations,
   however, resolver accepts the RRset as authentic, the resolver MUST bound set
   the work it puts into answering any
   particular query.

5.4 Example

5.4.1 Example TTL 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", RRSIG RR and "com".  What name each RR in the resolver should use when
   reconstructing authenticated RRset to a
   value no greater than the original signed data depends on minimum of:

   o  The RRset's TTL as received in the response;

   o  The RRSIG RR's TTL as received in the response; and

   o  The value of in the
   SIG RRSIG RR's Labels Original TTL field.

5.3.4 Authenticating A Wildcard Expanded RRset Positive Response

   If the value number of the SIG RR's Labels field labels in an RRset's fully qualified domain name is 6, then
   greater than the SIG RR's Labels field matches the number of labels in the owner name, and covering RRSIG RDATA, then the
   resolver should assume that this
   RRset is not the and its covering RRSIG RR were created as a result of wildcard
   expansion.  The resolver should therefore use "www.a.b.c.example.com"
   as the owner name when reconstructing  Once the original signed data for resolver has verified the signature check.

   If the value of the SIG RR's Labels field is less than 6, then the
   SIG RR's Labels count is less than the number of labels as described
   in Section 5.3, the
   RRset's owner name, and the resolver should assume that this RRset is
   the result of wildcard expansion.  The resolver should therefore
   reconstruct the original owner name by replacing the labels which
   appear must take additional steps to be verify the result
   non-existence of an exact match or closer wildcard expansion with a single "*."
   label.  For example, if match for the SIG RR's Labels field is 3,
   query.   Section 5.4 discusses these steps.

   Note that the response received by the resolver should reconstruct the original owner name by prepending "*." include all
   NSEC RRs needed to authenticate the
   last 3 labels response (see Section 3.3).

5.4 Authenticated Denial of the owner Existence

   A resolver can use authenticated NSEC RRs to prove that an RRset is
   not present in a signed zone.  Security-aware name of 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 answer RRset.  Thus, standard RRset authentication rules described in
   Section 5.3, then apply the
   resolver should use "*.c.example.com" NSEC RRsets as follows:

   o  If the owner requested RR name when
   reconstructing the original signed data.

   If matches the value owner name of an
      authenticated NSEC RR, then the SIG NSEC RR's Labels type bit map field is greater than 6, then
   this SIG lists
      all RR cannot possibly be valid for the answer RRset, types present at that owner name, and there
   is no point in attempting to validate the signature.

5.4.2 Examples of Authenticating 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 be an example of resolver can prove
      that the
   authentication process requested RR type does not exist by checking for non-existent "www.a.b.c.example.com",
   starting from an initial root key.

6. IANA Considerations

   This document introduces no IANA considerations.

   [10] contains a complete review of the IANA considerations introduced
   by DNSSEC.

      Editors' note: This may not be true anymore, since RR
      type in the AD and CD bit definitions are now in this document rather than in [10].

7. Security Considerations

   This document describes how map.  Since the DNS security extensions use public
   key cryptography to sign and authenticate DNS resource record sets.

   At this time, at least two substantial elements existence of the DNSSEC
   specification authenticated
      NSEC RR proves that the owner name exists in the zone, wildcard
      expansion could not have yet been used to be decided by match the working group.  The open
   opt-in issue would change elements such as what RRsets must be
   signed, would impact how wildcards are used, requested RR owner
      name and type.

   o  If the requested RR name would replace
   authenticated denial of existence with appear after an authenticated denial of
   security.  Handling of NSEC
      RR owner name and before the AD bit is also undecided.  The AD bit (as
   currently defined) is used name listed in that NSEC RR's Next
      Domain Name field according to indicate the security status of RRsets canonical DNS name order
      defined in [I-D.ietf-dnsext-dnssec-records], then no exact match
      for the response.  These items clearly raise security considerations
   and will be addressed here as these issues are resolved requested RR name exists in the
   working group.

   DNSSEC introduces zone. However, it is
      possible that a number of denial of service issues.  These issues
   will also wildcard could be addressed in a future version of these security
   considerations.

   Please see [9] for general security considerations related used to DNSSEC.

8. Acknowledgements

   This document was created from match the input requested RR
      owner name and ideas of several members
   of type, so proving that the DNS Extensions Working Group and working group mailing list.
   The co-authors 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 this draft would like an RRset, the resolver must be able to express their thanks for
   verify both that the comments queried RRset does not exist and suggestions received during that no
   relevant wildcard RRset exists.  Proving this may require more than
   one NSEC RRset from the revision zone.  If the complete set of these
   security extension specifications.

Normative References

   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [2]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

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

   [4]   Bradner, S., "Key words for use necessary NSEC
   RRsets is not present in RFCs a response (perhaps due to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [5]   Elz, R. and R. Bush, "Clarifications truncation), then
   a security-aware resolver MUST resend the query in order to attempt
   to obtain the DNS Specification",
         RFC 2181, July 1997.

   [6]   Vixie, P., "Extension Mechanisms for DNS full collection of 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 NSEC RR proves the existance of both itself and its
   corresponding RRSIG RR, a verifier MUST ignore the settings of the
   NSEC and 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
   RRSIG RR's Labels field.

   If the value of the RRSIG RR's Labels field is 6, then the RRSIG RR's
   Labels field matches the number of labels in the owner name, and the
   resolver should assume 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 of the RRSIG RR's Labels field is less than 6, then the
   RRSIG RR's Labels count is less than the number of labels in the
   RRset's owner name, and the resolver should assume that this RRset is
   the result of wildcard expansion.  The resolver should therefore
   reconstruct the original owner name by replacing the labels 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 to validate the signature.

5.5.2 Examples of Authenticating 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 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 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 DNS security extensions use public
   key cryptography to sign 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 the input and ideas of several members
   of the DNS Extensions Working Group and working group mailing list.
   The co-authors of this draft would like to express their thanks for
   the comments and suggestions received during 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 to the DNS
              Specification", RFC 2181, July 1997.

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

   [7]

   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
              3225, December 2001.

   [8]

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

   [9]

   [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-05
              draft-ietf-dnsext-dnssec-intro-06 (work in progress), February
              September 2003.

   [10]

   [I-D.ietf-dnsext-dnssec-records]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "Resource Records for DNS Security Extensions", draft-ietf-
         dnsext-dnssec-records-04 (work in progress), February 2003.

   [11]  Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-
         ietf-dnsext-dnssec-opt-in-04
              draft-ietf-dnsext-dnssec-records-04 (work in progress), February
              September 2003.

Informative References

   [12]

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

   [13]

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

   [14]

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

   [15]

   [I-D.ietf-dnsext-delegation-signer]
              Gudmundsson, O., "Delegation Signer Resource Record", draft-
         ietf-dnsext-delegation-signer-12
              draft-ietf-dnsext-delegation-signer-15 (work in progress), December
              June 2003.

   [I-D.ietf-dnsext-wcard-clarify]
              Halley, B. and E. Lewis, "Clarifying the Role 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. and B. Wellington, "Redefinition of 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. Algorithm For Handling Wildcard Expansion

   For zone (Z) and a name (N) that may occur in Z, the following
   algorithm finds all wildcard RRsets that match N or returns an NXT NSEC
   RRset that proves no wildcard expansion matches N. The algorithm was
   written for clarity, not efficiency:

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

         1. Construct S = sequence of all names in Z, sorted
                          into canonical order.

         2. If N exists in S
               There is an exact match an exact match for N.
               Return all RRsets associated with N
            Else
               Add the name that would immediately
               precede N in S to NSEC_SET.
            EndIf

         3. Replace the leftmost label of N with *

         4. If N exists in S and answers the query
               There is a positive wildcard match for N.
               Return all RRsets associated with N
            Else
               Add the NSEC for name that would immediately
               precede N in S to NSEC_SET.
               Return the NSEC_SET.
            EndIf

         5. Remove the leading * from N.

         6. If N exists in S
               There is a name that terminates the wildcard search.
               Add the NSEC for N.
               Return all RRsets associated with N to NSEC_SET and return NSEC_SET.
            Else
               Add the NSEC for name that would immediately
               precede N 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 DNSKEY 257 3 1 (
                              AQPGkQLwyHHfD8nkDxZSbErTBHLYdOKkVIoq
                              SJkBnpfABtFdiJBgZYcjCNExAFjlc/olW42g
                              TJYBRjs1INw3I08/h43L595Iq8fyhEyBoGOR
                              +6db+Q3oQ9G2EKpfMEPDLU6f7gYrHpzDHIjO
                              rsSftzmRYHou70oVQ7aBjd9ePPCOVw==
                              )
                  3600 RRSIG  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 DS     23677 1 1 (
                              F248F32298280A061736C93FB078A51C17CC
                              C291 )
                  3600 RRSIG  DS 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              k6fA3VfeR5UHu9L/+4y8HJrUubVHBdyFzMaa
                              8EpDYqw3vYEVsrL5YvXwoqrSZsSAxdIrUXoB
                              SzjbKFOq6HRxXjuLsJ2TLT90p6mg9ZHL57jH
                              FfmrNPuq58QwRWvwuOyaExJWEdxMIEIbvETz
                              YJs3G/9tNte9i25YtAuLHbD2UqY= )
                  3600 NSEC   ai.example. NS 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 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 RRSIG  A 1 2 3600 20031029215736 (
                              20030929215736 4638 example.
                              u/uV4xcu7KSVV+3Vtg8O0qTGlGHeFKU1vBQJ
                              x1QKLtolw/ZstzqIuRBI5fuF4JYxSwMoaI7b
                              JBFyZ3KkCCK88r1VjZTkicNvFG7RO3G2faxb
                              MualMbGfhcexJzRcoZsIXSb3+qtbAr4aKF7c
                              fdZ587NLR1Ns2GraGTztUDMSK/A= )
                  3600 NSEC   ns2.example. A RRSIG NSEC
                  3600 RRSIG  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 NSEC   *.w.example. A RRSIG NSEC
                  3600 RRSIG  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  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. MX RRSIG NSEC
                  3600 RRSIG  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 NSEC   x.y.w.example. MX 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 MX  1 xx.example.
                  3600 RRSIG  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 the DNSKEY RDATA
   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
   these DNSKEY RRs also has the SEP flag set and has been used to sign
   the apex DNSKEY RRset; this is the key which should be hashed to
   generate a DS record to be inserted into the parent zone.  The other
   DNSKEY is used to sign all the other RRsets in the zone.

   The zone includes a wildcard entry "*.w.example".  Note that the name that would immediately
               precede N
   "*.w.example" is used in S to NXT_SET.
            EndIf

         3. Replace constructing NSEC chains, and that the leftmost RRSIG
   covering the "*.w.example" MX RRset has a label count of N with *

         4. If N exists in S
               There 2.

   The zone also includes two delegations.  The delegation to
   "b.example" includes an NS RRset, glue address records, and an NSEC
   RR; note that only the NSEC RRset is signed.  The delegation to
   "a.example" provides a positive wildcard match for N.
               Return all DS RR; note that only the NSEC and DS RRsets associated with N
            Else
               Add
   are signed.

Intellectual Property Statement

   The IETF takes no position regarding the NXT for name validity or scope of any
   intellectual property or other rights that would immediately
               precede N in S might be claimed to
   pertain to NXT_SET.
            EndIf

         5. Remove the leading * from N.

         6. If N exists implementation or use of the technology described in S
               There is a name that terminates
   this document or the wildcard search.
               Add 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 NXT for N
   IETF's procedures with respect to NXT_SET rights in standards-track and return NXT_SET.
            Else
               Goto Step 3
            EndIf

         Note: the algorithm is guaranteed
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to terminate since
               eventually there will be made available, or the result of an attempt made to
   obtain a match general license or N will 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
               reduced required to zone name itself and practice
   this standard. Please address the zone name
               must exist in S. 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 assigns. 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.