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

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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on April 25, September 1, 2003.

Copyright Notice

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

Abstract

   This document is part of a family of documents that describe which describes the
   DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and protocol modifications
      that provide source which
   add data origin authentication for and data integrity to the DNS.  This
   document describes the DNSSEC protocol modifications.  The  This document
   defines the concept of zone
      signing is introduced and the zone format is modified to include
      KEY, SIG, NXT, and DS resource records.  If a resolver indicates
      support for DNSSEC, the response process is modified to include signed zone, along with the appropriate KEY, SIG, NXT, requirements for
   serving and DS resource records. resolving using DNSSEC.  These
      resource records are used by the techniques allow a
   security-aware resolver to authenticate the
      response. 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   Editors' Notes . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.1 Open Technical Issues  . . . . . . . . . . . . . . . . . . .  4
   1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . .  5  4
   1.3.3 Typos and Minor Corrections  . . . . . . . . . . . . . . . .  5
   2.    Zone Signing and Zone Format . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1   Inclusion of   Including KEY RRs in a Zone  . . . . . . . . . . . . . . .  7 .  6
   2.2   Inclusion of NXT   Including SIG RRs in a Zone  . . . . . . . . . . . . . . . .  7
   2.3   Inclusion of SIG   Including NXT RRs in a Zone  . . . . . . . . . . . . . . .  7 .  8
   2.4   Changes to the CNAME Resource Record.   Including DS RRs in a Zone . . . . . . . . . . .  8
   2.5   Inclusion of DS RRs in a Zone . . . . . .  8
   2.5   Changes to the CNAME Resource Record.  . . . . . . . . . . .  8
   2.6   Example of a Secure Zone . . . . . . . . . . . . . . . . . .  9  8
   3.    Constructing DNS Responses .    Serving  . . . . . . . . . . . . . . . . 10
   3.1   Indicating Resolver Support for DNSSEC . . . . . . . . . . . 10
   3.2   Inclusion of
   3.1   Including SIG RRs in a Response  . . . . . . . . . . . . . 11
   3.3   Inclusion of . 10
   3.2   Including KEY RRs In a Response  . . . . . . . . . . . . . 12
   3.4   Inclusion of . 11
   3.3   Including NXT RRs In a Response  . . . . . . . . . . . . . 12
   3.4.1 . 11
   3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12
   3.4.2
   3.3.2 Case 2: Query Name Does Not Exist Exist, and No Wildcard Matches . 13
   3.4.3 12
   3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches  . . 13
   3.5   Inclusion of
   3.4   Including DS RRs In a Response . . . . . . . . . . . . . . . 13
   3.6
   3.5   Responding to Queries for DS RRs . . . . . . . . . . . . . . 13
   3.7   Special Considerations
   3.6   Responding to Queries for Recursive/Caching Servers Type AXFR or IXFR  . . . . . . . . 15
   3.8
   3.7   Setting the AD and CD Bits in a Response . . . . . . . . . . 15
   3.9
   3.8   Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16
   4.    Authenticating DNS Responses    Resolving  . . . . . . . . . . . . . . . . 17
   4.1   Authenticating Referrals . . . . . . . . . 21
   4.1   Recursive Name Servers . . . . . . . . . 18
   4.2   Authenticating an RRSet Using a SIG RR . . . . . . . . . . 23
   4.2   Stub resolvers . 19
   4.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 19
   4.2.2 Reconstructing the Signed Data . . . . . . 24
   5.    Authenticating DNS Responses . . . . . . . . . 20
   4.2.3 Checking the Signature . . . . . . . 25
   5.1   Authenticating Referrals . . . . . . . . . . . . 22
   4.2.4 Authenticating Wildcard Expanded RRset . . . . . . 26
   5.2   Authenticating an RRSet Using a SIG RR . . . . . 23
   4.3 . . . . . . 27
   5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27
   5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28
   5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30
   5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31
   5.3   Authenticated Denial of Existence  . . . . . . . . . . . . . 23
   4.4 31
   5.4   Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   4.4.1 32
   5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32
   5.4.2 Examples of Authenticating a Response  . . . . . . 24
   5. . . . . . 33
   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 26
   6. 34
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 27
   7. 35
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 36
         Normative References . . . . . . . . . . . . . . . . . . . . 37
         Informative References . . . . . . . . . . . . . . . . . 29 . . 38
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 38
   A.    Algorithm For Handling Wildcard Expansion  . . . . . . . . . 31 40
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 32 41

1. Introduction

   The DNS Security Extensions (DNSSEC) modify several aspects of the
   DNS protocol.  The  Section 2 defines the concept of a signed zone signing is introduced and the
      zone format is modified to include KEY, SIG, NXT, and DS resource
      records as described in Section 2.  If
   lists the resolver has indicated
      support requirements for DNSSEC, the process of constructing a DNS response is
      also modified to include the appropriate KEY, SIG, NXT, and DS RR
      types. zone signing.  Section 3 defines how a resolver indicates support for
      DNSSEC, describes how the DNSSEC RR types are included in a
      response, and also describes the specgal processing rules required
   modifications to authoritative name server behavior necessary to
   handle queries for signed zones.  Section 4 describes the DS RR type. behavior of entities
   which include security-aware resolver functions Finally, Section 4 5
   defines how a resolver uses the 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] and RFC1035 [2].

   This document is part of a family of documents that which define the DNS
   security extensions.  The DNS security extensions (DNSSEC) (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and DNS protocol modifications that which
   add source data origin authentication and data integrity to the Domain Name System (DNS). DNS.  An
   introduction to DNSSEC and definition of common terms can be found in [8].
   [9].  A definition of the DNSSEC resource records can be found in [9].
   [10].  This document defines the DNSSEC protocol modificatinos.

      The reader to assumed to be familiar with the basic DNS concepts
      described in RFC1034 [1] and RFC1035 [2] and should also be
      familiar with common DNSSEC terminology as defined in [8]. modifications.

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

1.3 Editors 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.
      Although the opt-in issue is not resolved, progress on this
      document was still needed.  This text describes
   the NXT record as it was defined in RFC 2535 2535, and substantial
   portions of this document would need to be updated to incorporate
   opt-in.  The updates will be made if opt-in is adopted.

      The use the WG adopts opt-in.

   Use of the AD bit is described in section 3.8 and 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. 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 there is no RFC that defines the correct behavior (or RFCs provide conflicting
      answers), 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. dnssec-editors@east.isi.edu.
   To assist the editors, please provide enough context for us to quickly find
   the incorrect text. 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 and Zone Format

   DNSSEC defines the concept of a new process called signed zone.  A signed zone signing and adds the includes
   KEY, SIG, NXT, NXT and (optionally) DS resource records according to the rules
   specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4,
   respectively.  Any zone format.  The zone
      signing process is which does not include these records
   according to the first step rules in enabling resource record
      authentication for this zone.  After section must be considered unsigned.

      Editors' note: Should this be "MUST be considered unsigned"?

   DNSSEC requires a signed zone has been
      created and loaded, change to the KEY, SIG, NXT, and DS definition of the CNAME resource records can
      be included in responses (as decribed in
   record.  Section 3) and can be
      used by resolvers 2.5 changes the CNAME RR to authenticate responses (as describe in
      Section 4).  KEY, SIG, NXT, allow SIG and DS NXT RRs MUST NOT to
   appear at the same owner name as a CNAME RR.

   Section 2.6 shows a sample signed zone.

2.1 Including KEY RRs in unsigned
      zones.

      To sign a zone, the zone administrator generates one 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.  The zone's public pairs and uses the private key(s) are made
      available by storing them to sign
   authoritative RRsets in KEY resource records.  Other DNS
      public keys, such as public keys the zone.  For each private key used by TKEY and SIG(0), can also to
   create SIG RRs, there SHOULD be a corresponding KEY RR stored in at the
   zone apex.  All KEY RRs.  Once RRs at the zone apex MUST be zone keys.  (A zone
   key KEY records have been added to RR has the
      zone, Zone Key bit of the zone is sorted into a canonical form and NXT resource
      records are added Flags RDATA field set to enable authenticated denial one.
   See Section 2.1.1 of existence.
      The [10].)  Zone key KEY RRs MUST appear only at the
   zone administrator then signs every authoritative RRset apex.

   A signed zone MUST have at least one zone key KEY RR in its apex KEY
   RRset.  The KEY RRset at the zone using the apex MUST be self-signed by at
   least one private key(s) and the signatures are key whose corresponding public key is a zone key
   stored in SIG
      resource records. the apex KEY RRset.

      Editors' note: The resulting signed zone contains all data requirement listed in this paragraph may not be
      necessary anymore, since the original (unsigned) zone and also includes the new KEY, NXT,
      and SIG RRs.

      Section 2.1, Section 2.2, and Section 2.3 present the rules for
      the including KEY RRset is self-signed anyway
      (because the KEY, NXT, and SIG resource records in a zone
      (respectively).

      The whole zone signing process also requires is signed).  This is probably a change in the definition
      of pre-DS
      relic, but we spotted this a few hours before the CNAME resource record I-D deadline and Section 2.4 changes the CNAME RR
      to allow SIG and NXT RRs
      were too chicken to appear along with the CNAME RR.

      To enable authentication chains between DNS zones, a signed zone
      includes DS Resource Records for its signed delegations.  Section
      2.5 presents the rules for including DS resource records.

      Note that if a resource record in a signed zone is added,
      modified, or deleted,  the signatures associaates with this RRset
      MUST be updated and the NXT RR remove it on such short notice....

   Other public keys associated with the RRset's owner
      name MUST also be updated.  In addition, the zone MUST other DNS operations can be
      periodically resigned stored
   in order to maintain current SIG expiration
      dates and the zone keys SHOULD change periodically.  DNSSEC best
      practices documents are encouraged to provide recommendations for
      signature and key lifetimes.

   2.1 Inclusion of KEY RRs in a Zone

      A that are not marked as zone administrator generates a set of public/private keys.  Non-zone key pairs
      and uses the private key(s) to sign authoritative RRsets in the
      zone.  For each private zone KEY RRs
   MUST NOT appear at delegation names.  Non-zone key used to create SIG RRs, there
      SHOULD be a corresponding public KEY RR stored RRs also
   SHOULD NOT appear at the zone apex
      and the corresponding apex, because large KEY RR MUST have the Zone Key Flag (KEY
      RDATA Flag bit 7) set to 1. RRsets add
   processing time at resolvers.  Non-zone key KEY RR's with Zone Flag set MUST only RRs MAY appear at any
   other name in the zone.

2.2 Including SIG RRs in a Zone

   For each authoritative RRset in the zone apex.

      A signed zone MUST have (which excludes NS RRsets at least one zone KEY RR in its apex KEY
      set
   delegation points and the apex KEY set MUST be self-signed by at least one
      private key whose corresponding public zone KEY RR is stored in
      the apex KEY set.

      Other DNS public keys, such as those used by TKEY and SIG, can be
      stored in the zone using non-Zone KEY RR's (KEY RDATA Flag bit 7
      set to 0).  Non-zone KEY RR's MUST NOT appear at delegation names,
      but MAY appear at any other authoritative name in the zone.  A
      non-zone KEY RR SHOULD NOT appear at the apex name since this
      could lead to large apex KEY sets and requires added processing
      time at resolvers.

   2.2 Inclusion of NXT RRs in a Zone

      Each authoritative name in the zone MUST have an NXT resource
      record.  The NXT record indicates what are RR types are present at
      that name and indicates the next authortitive name in the zone.
      The collection of NXT or "next" resource records (RR) provide a
      chain of all authoritative names and RRsets in the zone and are
      used for authenticated denial of existence.  The process for
      constructing the NXT RR for a given name is described in [9].

   2.3 Inclusion of SIG RRs in a Zone

      For each authoritative RRset in the zone, there glue RRsets), there MUST be at least one SIG
   record that meets all of the following requirements:

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

   o  The SIG class is equal to the RRset class. class;

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

   o  The SIG Original TTL field is greater than or equal to the TTL of the RRset. RRset;

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

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

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

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

   The process for constructing the SIG RR for a given RRset is
   described in [9]. [10].  An RRset MAY have multiple SIG RR RRs associated
   with it.

      The

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

   The NS RRset that which appears at the zone apex name MUST be signed, but
   the NS RRsets that which appear at delegation owner names (child zones) 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 and any glue signed.  Glue address RRsets assoicated associated
   with
      child delegations MUST NOT be signed.

   2.4 Changes to

   The difference between the CNAME Resource Record.

      If a CNAME RR set of owner names which require SIG
   records and the set of owner names which require NXT records is
   subtle and worth highlighting.  SIG records are present at a name, RRs other than the SIG and owner
   names of all authoritative RRsets.  NXT
      MUST NOT be records are present at that name.

      The above the
   owner names of all names for which the signed zone is modification to authoritative
   and also at the original CNAME definition given
      in [1].  The original definition owner names of CNAME did not allow any other
      resource records to co-exist with a CNAME record, but delegations from the signed zone
      signing process associates to
   its children.  Neither NXT and nor SIG resource records with every
      authorititative name.  To resolve this conflict, are present (in the definition of parent
   zone) at the CNAME resource record owner names of glue address RRsets.  Note, however, that
   this distinction is modified to allow for the co-
      existence of most part only visible during the zone
   signing process, because NXT RRsets are authoritative data, and
   therefore are signed, thus any owner name which has an NXT RRset will
   have SIG RRs.

   2.5 Inclusion RRs as well in the signed zone.

2.3 Including NXT RRs in a Zone

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

2.4 Including DS RRs in a Zone

   The DS resource record is used to establish establishes authentication chains between DNS
   zones.  A signed delegation (child zone) DS RRset SHOULD
      provide its parent zone with be present at a DS RR for delegation point when the delegation.  All
   child zone is signed.  The DS
      RRsets stored in RRset MAY contain multiple records,
   each referencing a key used by the child zone to sign its apex KEY
   RRset.  All DS RRsets in a zone MUST be signedx signed and DS RRsets MUST NOT
   appear at non-delegation points or nor at a zone's apex.

      The

   A DS RR provided by the child SHOULD point to a KEY RR that which is present in the child's apex
   KEY set RRset, and the child's apex KEY RRset SHOULD be signed by the
   corresponding private key.  If the KEY RR
      is present in the child's apex KEY set, the KEY RR MUST have the
      Zone Key Flag set.

      Note that the process

   Construction of providing a DS RR can be accomplished by
      either directly sending requires knowledge of the DS corresponding KEY
   RR to in the child zone, which implies communication between the child
   and parent or zones.  This communication is an operational matter not
   covered by sending a
      KEY RR this document.

2.5 Changes to the parent CNAME Resource Record.

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

   This is a DS
      RR for modification to the original CNAME definition given KEY RR.  The parent/child communication needs to
      be authenticated in order [1].
   The original definition of the CNAME RR did not allow any other types
   to prevent an adversary from inserting co-exist with a
      false DS RR.  DNSSEC operational CNAME record, but a signed zone requires NXT and best practices documents are
      encouraged
   SIG RRsets for every authoritative name.  To resolve this conflict,
   the definition of the CNAME resource record is hereby modified to provide guidelines
   allow for providing a DS RR. the co-existence of NXT and SIG RRsets.

2.6 Example of a Secure Zone

            secure

      {{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 a
      (small) complete signed zone.

   The apex KEY set includes two KEY RRs RRs, and the KEY RDATA Flags
   indicate that each of these KEY RRs is a zone key.  The first zone
   KEY is used to sign the apex KEY set RRset, and 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 and "host1.example.com"; this KEY and might be used by SIG(0) to
   authenticate transactions from this host.

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

   The zone also includes two delegations.  The delegation to
      unsecure.example.com
   "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
   "secure.example.com" delegation has provided provides a DS RR RR, and note that only
   NXT and DS RRsets are signed.

3. Constructing DNS Responses

      Unless Serving

   This section describes the behavior of a resolver has indicated security-aware authoritative
   name server.  A security-aware authoritative name server MUST support for DNSSEC, no changes are
      made to
   the standard (non-secure) DNS response and EDNS0 [6] message size extension, MUST support a server simply
      behaves as if no DNSSEC RR types were present.  This helps avoid
      backwards compatability issues and also avoids increasing the message size of (non-secure) DNS responses.  Servers MUST NOT include any
      DNSSEC RR types (KEY NXT SIG DS) unless the resolver has indicated
   at least 1220 octets, and SHOULD support for DNSSEC using one a message size of the mechanisms 4000
   octets [8].  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 3.1.

      If 4.

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

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

   o  NXT RRs that which can be used to provide authenticated denial of
      existence are automatically MUST be included in the response automatically according
      to the rules in Section 3.4. 3.3;

   o  Either DS RRs (or or an NXT RR if proving that no DS RRs are present) are automatically exist MUST be
      included in referals referrals automatically according to the rules in
      Section 3.5. 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, or which has the DO bit set to
   zero, MUST treat the SIG, KEY, and NXT RRs as it would any other
   RRset, and MUST NOT perform any of the additional processing
   described above.  Since the DS RR is the only RR type that appears only on has the
         upper side peculiar property of a delegation, any query for
   only existing in the parent zone at delegation points, DS RR type
         requires RRs always
   require some special processing processing, as described in Section 3.6.

      Section 3.7 discusses how these changes impact caching servers and
      recursive servers. 3.5.

3.1 Indicating Resolver Support for DNSSEC

      A resolver has indicated it supports DNSSEC if any of the
      following hold:

         The query explictly requests a KEY, NXT, SIG, or DS RR type.

         The query implicitly requests a KEY, NXT, SIG, or DS by
         requesting a meta-type that matches the KEY, SIG, NXT, or DS
         RRs.  In particular, ANY, IXFR, and AFXR queries implictly
         match the DNSSEC RR types and DNSSEC RRs MUST be returned in
         response to a query for ANY, IFXR, or AXFR.

         The resolver has explicity requested DNSSEC by setting the
         DNSSEC OK bit in the ENDS0 header.

      The "DNSSEC OK" (D0) bit is used for explicit notification of
      DNSSEC support.  The DO bit is defined in [9] and setting the DO
      bit to one in a query indicates that the resolver is able to
      accept DNSSEC security RRs.  The DO bit cleared (set to zero)
      indicates the resolver is unprepared to handle DNSSEC security RRs
      and those RRs MUST NOT be returned in the response (unless DNSSEC
      security Including SIG RRs are explicitly requested in the query or implicitly
      requested by the use a meta-RR type such as ANY, IXFR, or AFXR).
      The DO bit of the query MUST be copied in the response.

      In the event a server returns a NOTIMP, FORMERR or SERVFAIL
      response to Response

   When a query that has the DO bit set, the resolver SHOULD
      NOT expect DNSSEC security RRs and SHOULD retry the query without
      EDNS0 in accordance with Section 5.3 of RFC2671 [6].

      The absence of DNSSEC data in response to a query with the DO bit set MUST NOT be taken to mean no security information is available
      for that zone since the response may have be forged or may be a
      non-forged response to an altered (DO bit cleared) query.

   3.2 Inclusion of SIG RRs in a Response

      If one, the resolver has indicated support for DNSSEC, servers authoritative name server
   SHOULD attempt to send SIG RRs that which can be used to authenticate the RR
      sets
   RRsets in the response.  The inclusion  Inclusion of SIG RRs in a response is
   subject to the following rules:

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

   o  When an a signed RRset is placed in the authority Authority section, its SIG
      RRs are also placed in the authority Authority section.  The SIG 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 RRs, the response MUST be considered
         truncated. truncated, and the TC bit
      MUST be set.

   o  When an a signed RRset is placed in the additional Additional section, its SIG
      RRs are also placed in the additional Additional section.  If space does not
      permit the inclusion of these SIG RRs, the response MUST NOT be
      considered truncated.

   3.3 Inclusion of truncated just because these SIG RRs didn't fit.

3.2 Including KEY RRs In a Response

      If the resolver

   When a query has indicated support for DNSSEC and the query DO bit set to one and requests the SOA or NS RRs, RRs
   at the apex of a signed zone, then a security-aware authoritative
   name server for that zone SHOULD return the KEY RRset with the same
   name in the additional Additional section.  If not all
      additional information Additional section processing
   results in more data than will fit in the response, type A and AAAA response message, address
   glue RRs have higher priority than KEY RRs.  The  SIG RR(s) associated
   with the KEY RR set RRset SHOULD also be included in the
      additional Additional section
   (see including SIG RRs in Section 3.2).

   3.4 Inclusion of 3.1).

      Editors' note: Didn't the WG decide that DS RR removes the need
      for Additional section processing for KEY RRs?  If so, this
      subsection should be deleted.

3.3 Including NXT RRs In a Response

      If

      Editors' note: This whole section uses the resolver has indicated support 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 DNSSEC, least
      one RR.   Better phrasing needed.

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

   Case 1: the The query name exists, but the requested RR type does not
      exist.

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

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

   Note that, in each case, a set of NXT RRs is included to provide
   authenticated denial of existence.

   NXT RRs are also included in a referal referral response if when no DS RR is
      present.  In
   present; in this case, the NXT RR is used to prove proves that no DS RR exists for the delegation and referals
   delegation.  Referrals are discussed in more detail in Section 3.5.

      Note that in every case the NXT RRs are included to provide
      authenticated denial of existence.

   3.4.1 3.4.

3.3.1 Case 1: Query Name Exists, but RR Type Not Present

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

   Note that that, since the query name exists, an no wildcard expansion applies
   to this query, and a single NXT RR suffices to prove the requested
   type does not exist.  Since the name exists
      in the zone, an NXT RR for that name also exists and lists RR
      types present at the name.  Since the query name exists, no
      wildcard expansion applies to this query.

   3.4.2

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

   If the query name does not exist exist, and no wildcard expansion matches
   the query, then the authority Authority section of the response MUST include an
   the following NXT RRs:

   o  An NXT RR proving that proves there was no exact match for the name name; and MUST
      also include

   o  An NXT RRs RR proving that prove there was no wildcard which would have
      matched the query.

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

      Editors' note: Should lack of space does not permit to include the inclusion of these NXT
      RRs, SIGs cause the response MUST
      packet to be considered truncated. truncated?

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

   3.4.3

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

   If the query name does not exist and exist, but a wildcard expansion matches can be
   used to return a positive match to the query, then the wildcard card wildcard-
   expanded answer (and and any SIG RRs associated with the wildcard RR) are RR MUST
   be returned in the answer Answer section.  The authority Authority section of the
   response MUST include the following NXT
      RRs RRs:

   o  An NXT RR which proves that prove there were no exact matches for the name
      QNAME and MUST
      also include QTYPE; and

   o  An NXT RRs to prove RR which proves that there are no closer wildcard entry would entries
      which could have
      matched this been expanded to match the query.

   If space does not permit inclusion of these NXT RRs, the response
   MUST be considered truncated, and 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?

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

   3.5 Inclusion of

3.4 Including DS RRs In a Response

      If the resolver

   When a query has indicated support for DNSSEC, 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 DS RRset if also
   the DS RRset exists. and its associated SIG RR(s).  The NS RRset MUST be
   placed before the DS RRset (and and its assoicated associated SIG RRs).

      If the resolver has indicated support for DNSSEC, 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 parent the NS RRset and also
   the parent NXT RR if and associated SIG RR(s) which proves that the DS RRset
   does not exist.  The NS RRset MUST be placed before the NXT RRset (and and
   its
      assoicated associated SIG RRs). RR(s).

   This increases the size of referral messages messages, and may cause some or
   all glue RRs to be omitted.  If space does not permit the inclusion
   of the DS or NXT RRset (NXT RRset) and its assoicated associated SIG RRs, the response MUST be
   considered truncated.

   3.6 truncated, and the TC bit MUST be set.

3.5 Responding to Queries for DS RRs

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

   If a name server is authoritative for the parent zone at a delegation
      point zone, and receives a
   query for the DS record at the delegation delegated name, then the name server
   MUST return the DS RRset from the parent zone.  This is true 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 at a delegation
      point and zone, is not
   authoritative for the parent zone, and receives a query for the DS
   record at the delegated name, there is no
      natural response.  The obvious response, because
   the child zone is not authoritative for the DS record at the child
   zone's apex apex, and the authoritative DS RR is only stored at the
   parent.

   If the name server allows recursion recursion, and the RD bit is set in the
   query, the name server MAY perform recursion to find the DS record
         at
   for the delegation point 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) + NXT + SIG(NXT)]

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

   For example, suppose that "example.com" is a delegation point point, and a
   name server receives a query for the "example.com" DS RRset is received by a server. 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" and "example.com", is not
         authortative
      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 (provided the RD bit was set
         in the query). 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) + NXT + SIG(NXT)]

   3.7 Special Considerations

3.6 Responding to Queries for Recursive/Caching Servers

      A Type AXFR or IXFR

   DNSSEC does not change the DNS zone transfer process.  A signed zone
   will contain SIG, KEY, NXT, 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 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, 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 RRs appear in both the parent and child
   zones at a delegated name, and that the NXT 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 RR at a
   delegated name MUST be included zone transfers of the parent zone,
   while the NXT 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.  If the CD bit is set to one, it indicates
   that the resolver is willing to perform authentication, 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 local name
   server policy.  The CD bit MAY be used in constructing the local name
   server policy.  If local name server policy does perform
   authentication, any RRsets rejected by the local authentication
   policy MUST NOT be returned in a response (regardless of the CD bit).

   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

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

      example.com.    SOA     (...)
                      SIG     SOA ...
                      NS      a.example.com.
                      NS      b.example.com.
                      SIG     NS ...
                      MX      10 a.example.com
                      SIG     MX ...
                      KEY     ...
                      SIG     KEY ...
                      NXT     *.example.com.
      *               MX      10 a.example.com.
                      SIG     MX ...
                      NXT     a.example.com.
      a               A       10.10.10.1
                      SIG     A ...
                      NXT     b.example.com.
      b               A       10.10.10.2
                      SIG     A ...
                      NXT     c.example.com.
      c               CNAME   a.example.com.
                      SIG     CNAME
                      NXT     sub.example.com.
      sub             NS      ns.sub.example.com.
                      SIG     NS
                      DS      ...
                      SIG     DS
                      NXT     *.example.com.
      ns.sub          A       10.10.10.3
      sub-nosig       NS      ns.sub-nosig.example.com.
                      NXT     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 CNAME
         a.example.com.         IN A   10.10.10.1
                                IN SIG A
      AUTHORITY:
         example.com.           IN NS  a.example.com.
                                IN NS  b.example.com.
                                IN SIG NS ...
      ADDITIONAL:
         a.example.com.         IN A   10.10.10.1
                                IN SIG A ...
         b.example.com.         IN A   10.10.10.2
                                IN SIG 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 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 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 ;; (DS bit not set)
                                     IN  SIG NXT ...
      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 SOA ...
         c.example.com.        IN  NXT sub.example.com. ...
                               IN  SIG NXT ...
         *.example.com.        IN  NXT a.example.com. ...
                               IN  SIG NXT ...
      ADDITIONAL:
         example.com.          IN  KEY ...
                               IN  SIG KEY ...

   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 MX ...
      AUTHORITY:
         example.com.          IN  NS  a.example.com.
                               IN  NS  b.example.com.
                               IN  SIG NS ...
         c.example.com.        IN  NXT sub.example.com.
                               IN  SIG NXT ...
      ADDITIONAL:
         a.example.com.        IN  A   10.10.10.1
                               IN  SIG A ...
         b.example.com.        IN  A   10.10.10.2
                               IN  SIG 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] OPT pseudo-RR with
   the DO [7] 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] 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,
   or SIG 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 RR
   which the resolver needs to authenticate a NODATA response.  In
   general it is not possible for a resolver to retrieve missing NXT
   RRs, since the resolver will have no way of knowing the owner name of
   the missing NXT RR, but in the specific case of a NODATA response,
   the resolver does know the name of the missing NXT 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 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 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 be capable of being
   preconfigured with multiple trusted public keys.  Since a 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 with the (as yet unsettled) opt-in proposal.

      All of this advice has been discussed in WG meetings, and as far
      as the editors know these recommendations are not controversial,
      but it is up to the WG to decide whether this sort of
      implementation advice belongs in this document.

4.1 Recursive Name Servers

   As explained in [9], 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 name server role and the code which implements the security-
   aware resolver role, respectively.

   The resolver side of a security-aware recursive name server MUST set
   the DO bit on recursive when sending requests, regardless of the status state of the DO
   bit on in the initiating
      resolver request. request received by the name server side.  If
   the initiating resolver request does not have the DO bit set, the recursive DNSSEC-aware name server
   side MUST remove any DNSSEC security RRs before returning from the data response sent to the client,
      however cached data
   initiating resolver, but the resolver side MUST NOT be modified.

      A 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 by piecing together the responses cached data it has received in response to
   previous from other queries that requested different names QNAMEs, QTYPEs, or RR types.
   QCLASSes.  A cache typically
      does not have access to the complete zone and thus it can be
      difficult for a caching security-aware recursive name server to determine the proper SIG, NXT,
      KEY, and DS SHOULD NOT use NXT
   RRs for from one negative response to synthesize a given response for a
   different query.  A caching security-aware recursive name server SHOULD
      cache each NOT
   use a previous wildcard expansion to generate a response single atomic entry indexed by to a
   different query.

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

   The name server side of a security-aware recursive name server MUST
   pass the response and sense of the all CD bit to the assoicated DNSSEC RR
      types).  The cache SHOULD discard resolver side along with the entire entry when any RR in rest
   of an initiating query, so that the resolver side will know whether
   whether or not it is required to verify the response expires.

   3.8 Setting data it returns
   to the AD and CD Bits in name server side.

      Editors' note: What should a Response

      DNSSEC allocates two new bits in the DNS message header section:
      The CD (checking disabled) bit 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 the AD (authentic data) bit.
      These bits are defined in [9] and their use is described below.

      The CD DO [7] bit is set by the 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 of 4000 octets, and
   MUST be copied in advertise the
      response.  If supported message size using the CD bit is set to one, it indicates "sender's UDP
   payload size" field in the EDNS OPT pseudo-RR.  A security-aware stub
   resolver
      is willing MUST handle fragmented UDP packets correctly regardless of
   whether any such fragmented packets were received via IPv4 or IPv6.
   Please see [8] for discussion of these requirements.

   A security-aware stub resolver MUST support the DNSSEC RR types, at
   least to perform authentication and the server need extent of not
      perform authentication on the RRsets in mishandling responses just because they
   contain DNSSEC RRs.   A security-aware stub resolver MAY include the response.

      Regardless
   DNSSEC RRs returned by a security-aware recursive name server as part
   of the CD bit, data that it the server MAY choose stub resolver hands back to perform
      authentication (or choose the application
   which invoked it, but is not required to perform authentication) according
      to do so.

   A security-aware stub resolver SHOULD NOT set the local server policy.  The CD bit MAY be used in
      constructing when sending
   queries, since, by definition, a security-aware stub resolver does
   not validate signatures and thus depends on the local server policy.  If local security-aware
   recursive name server policy does to perform authentication, any RRsets rejected by the local
      authentication policy MUST validation on its behalf.

      Editors' note: Should this SHOULD NOT be returned in a response
      (regardless of the CD bit).

      The AD bit is set by the server and indicates the data in the
      response has been authenticated by the server, according to the
      local server policy.  The AD bit MUST NOT?

   A security-aware stub resolver MUST NOT be set place any reliance on a response
      unless all of the RRsets in the answer and authority sections have
      met
   signature validation allegedly performed on its behalf except when
   the servers local authentication policy.  A security-aware stub resolver MUST NOT
      use the AD bit unless unless it communicates with obtained the data in question from a
   trusted security-aware recursive name server over via a secure transport mechanism and is explicitly configured to trust
      the server's policy.  DNSSEC best practices documents are
      encouraged to provide server policy recommendations.

   3.9 Example DNSSEC Responses

      example of A and SIG

      example of apex KEY

      example of signed delegation (DS) and unsigned delegation (NXT)

      example of auth denial (includes NXT for wildcards)
   4. channel.

5. Authenticating DNS Responses

   In order to use DNSSEC RRs for authentication, a security-aware
   resolver requires
      some intial 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.  In the  The remainder of this section assumes
   that the resolver has used some
      unspecified off-line mechanism and somehow obtained an initial set of
   authenticated KEY RRs.

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

   1.  Verify that the initial KEY RR appears in the apex KEY RRset RRset, and
       verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7)
       set to 1. one.

   2.  Verify that there is some SIG RR that which covers the apex KEY RRset RRset,
       and that the combination of the SIG RR and the initial KEY RR
         authenticate
       authenticates the KEY RRset.  The process for using a SIG RR to
       authenticate an RRset is described in Section 4.2. 5.2.

   Once the resolver has authenticated the apex KEY RRset has been authenticated using an
   initial KEY RR, delegations from that zone can be authenticated using
   DS RRs.  This allows a resolver to start from an initial externally
      authenticated key, and use
   DS RRsets to recursively proceed recursively down the DNS tree to obtain obtaining other
   apex KEY RRsets.  If the resolver was
      initially configured were preconfigured with a root KEY RR
   RR, and if every delegation had a DS RR assoicated associated with it, then the
   resolver could obtain any apex KEY RRset.  The process of using DS
   RRs to authentic a referal authenticate referrals is described in Section 4.1. 5.1.

   Once the resolver has authenticated a zones zone's apex KEY RRset has been authenticated, RRset, Section 4.2
   5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and
   SIG RRs from the zone to authenticate any other RRsets in the zone.
   Section 4.3 5.3 shows how the resolver can use authenticated NXT RRsets
   from the zone to prove that an RRset is not present in the zone.

      If the

   When a resolver has indicated indicates support for DNSSEC, DNSSEC aware
      servers SHOULD a security-aware name
   server should attempt to provide the necessary KEY, SIG, NXT, and DS RRets
   RRsets in a response (see Section 3).  However, a security-aware
   resolver may still receive a response which that lacks the approriate
   appropriate DNSSEC RRs may result from RRs, whether due to configuration issues such as a non-DNSSEC aware cache that removes or fails
      request
   security-oblivious recursive name server which accidently interfere
   with DNSSEC RRs or may result from an intentional due to a deliberate attack where in which an adversary
   forges a response, strips DNSSEC RRs from a response
      forges, response, or modifies the a
   query so that DNSSEC RRs appear not to be requested.  The absence of
   DNSSEC data in a response MUST NOT by itself be taken to mean as an
   indication that no authentication information is available. 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
   zone, or if the zone's parent is signed and the delegation at from the
   parent contains a DS RRset.  DNSSEC best practices documents are encouraged to
      provide guidance on how a resolver responds if DNSSEC RRs are
      expected, but can not be obtained.  DNSSEC best practices
      documents are also are encouraged to provide guidance on how a
      resolver responds if the expected DNSSEC RRs are obtained but
      appear invalid (e.g.  all SIG RRs are expired).

   4.1

5.1 Authenticating Referrals

   Once the apex KEY RRset for a (parent) signed parent zone has been
   authenticated, DS RRsets can be used to authenticate a referal the delegation
   to a delegation (child zone). signed child zone.  A DS RR identifies a KEY RR in the
      child's child
   zone's apex KEY RRset.  The DS RR RRset, and contains a cryptographic digest of the
      child's
   child zone's KEY RR and a RR.  A strong cryptographic digest algorithm ensures
   that an adversary can not easily generate a KEY RR that matches the
   digest.  Thus  Thus, authenticating the digest allows a resolver to
      safely declare
   authenticate the matching child KEY RR to is also authentic.
      This RR.  The resolver can then use this
   child KEY RR is then used to authenticate the entire child apex KEY RRset.

   Given a DS RR for a delegation (child zone), delegation, the delegation's
      (child zone's) child zone's apex KEY RRset is considered to can
   be authentic authenticated if all of the following hold:

   o  The DS RR has been authenticated using some KEY RR in the parent's
      apex KEY RRset (see Section 4.2). 5.2);

   o  The Algorithm, Key Tag, Algorithm and Digest fields Key Tag in the DS RR match the algorithm, key tag, Algorithm field
      and digest the key tag of a KEY RR present in the
         child's child zone's apex KEY RRset. 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 RR in the child zone has the Zone Flag bit set to
      one, the corresponding private key has signed the child zone's
      apex KEY RRset, and the resulting SIG RR authenticates the child's child
      zone's apex KEY RRset.

   If the referal referral from the parent zone did not contain a DS RRset, the
   response SHOULD should have included an a signed NXT RRset proving that proves no DS
   RRset exists for the delegation delegated name (see Section 3.5). 3.4).  A security-
   aware resolver SHOULD MUST send the parent a query for the DS RRset if the
   referral includes neither a DS RRset or nor a NXT RRset is included in proving the referal.
   nonexistence of the DS RRset (see Section 4).

   If the resolver authenticates an NXT RRset that which proves that no DS
   RRset is present for this zone, then there is no authentication path
   leading from the parent to the child.  If the resolver has an initial
   KEY RR that which belongs to the child zone (or or to any delegation below the
   child zone), zone, this initial KEY RR MAY be used to re-
      establish re-establish an
   authentication path.  If no such initial KEY RR exists, the resolver
   can not authenticate RRsets at or below the child zone.

   Note that, for a signed delegation delegation, there are two NXT RRs associated
   with the delegation delegated name.  One NXT RR resides at in the parent zone, and
   can be used to prove whether a DS RRset exists for the delegation delegated
   name.  A  The second NXT RR resides at in the child zone zone, and identifies
   which RRsets are present at the apex in of the child zone.  The parent
   NXT RR and child NXT RR can always be distinguished distinguished, since the only SOA
   bit will be set in the child NXT RR will specify an SOA RR set exists at and clear in the name. parent NXT RR.
   A security-aware resolver MUST only use the parent NXT RR when proving attempting
   to prove that a DS RRset does not exist.

   4.2

5.2 Authenticating an RRSet Using a SIG RR

   A resolver can use a SIG RR (and and its corresponding KEY RR) is used by a resolver RR to
      authentic an RRset. attempt
   to authenticate RRsets.  The resolver first checks the SIG RR is first checked to
   verify 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 signed data is then constructed by appending the SIG RDATA
   (excluding the Signature Field) with the covered RRset
      (in canonical form). form of the
   covered RRset.  Finally, resolver uses the public key and signature and
      used
   to authenticate the signed data.  Section 4.2.1, 5.2.1, Section
      4.2.2, 5.2.2, and
   Section 4.2.3 5.2.3 describe each step in detail.

   4.2.1

5.2.1 Checking the SIG RR Validity

      An

   A security-aware resolver can use a SIG RR can be used to authenicate authenticate an RRset
   if all of the following conditions hold:

   o  The SIG RR and the RRset MUST have the same owner name and the
      same
         class. class;

   o  The SIG RR's Signer's Name field MUST be the name of the zone that
      contains the RRset. RRset;

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

   o  The number of labels in the RRset owner name MUST be greater than
      or equal to the value in the SIG RR's Labels field. field;

   o  The resolver's notion of the current time MUST be less than or
      equal to the time listed in the SIG RR's Expiration field. field;

   o  The resolver's notion of the current time MUST be greater than or
      equal to the time listed in the SIG RR's Inception field. field;

   o  The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
      match the owner name, algorithm, and key tag for some KEY RR in
      the zone's apex KEY RRset. RRset;

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

   It is possible that for more than one KEY RR matches to match the conditions
   above.  In this case, the resolver can not determine predetermine which KEY RR
      is used
   to use to authenticate the signature and the resolver signature, MUST try each matching KEY RR
   until the resolver has either validated the signature or all has run out
   of matching KEY RRs have failed. keys to try.

   Note that the this authentication process is only meaningful if the
   resolver first authenticates a the KEY RR before using it to validate
      a signature.
   signatures.  The matching KEY RR is considered to be authentic if if:

   o  The apex KEY RRset containing the KEY RR is considered
         authentic authentic;
      or

   o  The RRset covered by the SIG RR is the apex KEY RRset itself itself, and
      the KEY RR either matches an authenticated DS RR from the parent
      zone or matches some initial a DS RR or KEY RR/DS RR that is known which the resolver has been
      preconfigured to believe to be authentic.

   4.2.2

5.2.2 Reconstructing the Signed Data

   Once the SIG RR has met the validity requirements described in
   Section 4.2.1, 5.2.1, the original signed data resolver needs to be reconstructed. reconstruct the original signed
   data.  The original signed data includes SIG RDATA (excluding the
   Signature field) and the canonical form of the RRset.  Aside from
   being ordered, the canonical form of the RRset in cannonical order and might also differ from
   the RRset received in the DNS response RRset due to DNS name compression, TTL decrementing by a cache, decremented TTLs, or the RRset may be the
      result of
   wildcard expansion.  The resolver should use the following algorithm is used to
      reconstuct
   reconstruct the original signed data:

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

            "|" denotes append concatenation

            SIG_RDATA is the wire format of the SIG RDATA fields with
               the Signature field excluded. excluded and the Signer's Name in cannonical
               canonical form.

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

               class is the RRset's class

               type is the RRset type and all RRs in the class

               OrigTTL is the value from the SIG Original TTL field

               All names in the RDATA field are in canonical form

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

            To calculate the name:
               let sig_labels = the value of the SIG Labels field

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

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

               if sig_labels = fqdn_labels,
                   name = fqdn

               if sig_labels < fqdn_labels,
                  name = "*." | the leftmost sig_label labels of the
   	                     fqdn

               if sig_labels > fqdn
                  the SIG RR did not pass the necessary validation
                  checks and MUST NOT be used to authenticate this
                  RRset.

      An

      Editors' note: The algorithm above needs to be cross-checked very
      carefully against the definitions in [10].

   Section 5.4.1 gives an example of original name calculation is given in Section 4.4.1. calculation.  The
   canonical form forms for names and RRsets is are defined in [9]. [10].

   NXT RRsets present at a delegaion name delegation boundary require special processing.
   There are two distinct NXT RRsets associated with a signed
      delegation delegated
   name.  One NXT RRset resides at in the parent zone, and specifies which
   RRset are present at the parent.  A parent zone.  The second NXT RRset resides
   at the child zone zone, and identifies which RRsets are present at the
   apex in the child zone.  The parent NXT RRset and child NXT RRset can
   always be distinguished since only the child NXT RRs will specify an
   SOA RR set RRset exists at the name.  When
      constructing reconstructing the original NXT RRset,
   RRset for the delegation from the parent zone, the NXT RRs MUST NOT
   be combined with NXT RRs from the child (and vice versa).

   4.2.3 zone, and when reconstructing
   the original NXT RRset for the apex of the child zone, the NXT RRs
   MUST NOT be combined with NXT RRs from the parent zone.

   Note also that each of the two NXT RRsets at a delegation point has a
   corresponding SIG RR with an owner name matching the delegated name,
   and each of these SIG RRs is authoritative data associated with the
   same zone 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 the Signature

   Once the SIG RR resolver has met validated the validity requirements SIG RR as described in Section 4.2.1
   5.2.1 and reconstructed the original signed data has been reconstructed as described in
   Section 4.2.2, 5.2.2, the resolver can attempt to use the cryptographic
   signature is used to authenticate the signed data (and signed data, and thus (finally!)
   authenticate the RRset). RRset.

   The Algorithm field in the SIG RR identifies the cryptographic
   algorithm used to validate generate the signature.  The signature itself is
   contained in the Signature field of the SIG RDATA RDATA, and the public key
      used
   to authenticate this used generate the signature is contained in the Public Key field
   of the matching KEY RR(s) (found in Section 4.2.1).  [9] 5.2.1).  [10] provides a
   list of algorithm types types, and provides pointers to the documents that
   define each algorithm's use.

   Note that it is possible that for more than one KEY RR matches to match the
   conditions in Section 4.2.1. 5.2.1.  In this case, the resolver can not only
   determine which KEY RR is used to authenticate the signature and
      the resolver MUST try by trying each matching KEY RR key until the resolver has
   either validated succeeds in validating the signature or all matching KEY RRs have
      failed. runs out of keys to
   try.

   If the SIG RR Labels field of the SIG RR is not equal to the number of
   labels in the RRsets RRset's fully qualified domain owner name, then the RRset is a
   either invalid or the result of wildcard expansion.  The resolver
   MUST verify the that wildcard expansion was applied properly before
   considering the RRset is considered authentic.  The
      RRset and SIG RR MUST to be discarded if the resolver proves the
      wildcard was applied improperly. authentic.  Section 4.2.4 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 need to be tested
   RRs, and determines how to resolve conflicts if these SIG RRs lead to
   differing results.

   If the resolver accepts the RRset is accepted as authentic, the resolver MUST set
   the SIG RR RR's TTL and the TTL of each RR in the authenticated RRset MUST be set to
   the minimum
      of

         the RR of:

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

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

   o  The value in the SIG RRs RR's Original TTL field
   4.2.4 field.

5.2.4 Authenticating A Wildcard Expanded RRset Positive Response

   If a SIG RR's the number of labels in an RRset's fully qualified domain name does not equal is
   greater than the Labels field in the covering SIG RDATA, then the
   RRset and its covering SIG RR (and its covered RRset) were created as a result of wildcard
   expansion.  Once the
      signature resolver has been verified the signature as described in Section 4.2,
      additional steps are required to verify 1) no intermediate name
      cancels the use of the wildcard and 2) no more specific wildcard
      name could have been used to create this RRset.

      Intermediate label names can be formed from the fully qualified
      domain name by removing the rightmost labels and are used to prove
      the wildcard was used properly.  For example,
      "www.a.b.c.example.com." has intermediate names of
      "a.b.c.example.com", "b.c.example.com", "c.example.com",
      "example.com", and "com".  For each intermediate label name whose
      label count is greater the SIG RR Labels field, the resolver MUST
      obtain and authenticate NXT RRs that prove:

         the intermediate label name does not exist (otherwise this
         label would cancel
   in Section 5.2, the wildcard) resolver must take additional steps to verify the name "*.intermediate_label_name" does not exist (otherwise
         this
   non-existence of an exact match or closer wildcard would take precedence) match for the
   query.   Section 5.3 discusses these steps.

   Note that the response SHOULD received by the resolver should include all
   NXT RRs needed to the authenticate the response (see Section Section 3.4).

   4.3 3.3).

5.3 Authenticated Denial of Existence

   A resolver can use authenticated NXT RRs to prove that an RRset is
   not present in a signed zone.  NXT RRsets SHOULD be  Security-aware name servers should
   automatically
      included in the response, provided the zone is signed and the
      resolver has indicated support include any necessary NXT RRs for DNSSEC. signed zones in their
   responses to security-aware resolvers.

   Security-aware resolvers MUST first authenticate NXT RRsets are
      authenticated according
   to the standard RRset authentication rules described in Section 4.2 and are applied 5.2,
   then apply the NXT RRsets as follows:

   o  If the requested RR name matches the owner name of an
      authenticated NXT RR, then the NXT RR's type bit map field lists
      all RR types present at that owner
      name MUST be listed in the NXT RR's Type Bit Map field.  A name, and a resolver can prove
      that the requested RR type does not exist by
      presenting checking for the RR
      type in the bit map.  Since the existence of the authenticated NXT RR's Type Bit Map
      field.  Also, since
      RR proves that the owner name exists in the zone, no wildcard
      expansion could be not have been used to match the requested RR owner
      name and type.

   o  If the requested RR name logically appears would appear after an authenticated NXT
      RR owner name and logically appears before the name listed in that NXT RR's Next
      Domain Name field, field according to the canonical DNS name order
      defined in [10], then no exact match for the requested RR name
      is not present
      exists in the zone.  However, it is possible that a wildcard could
      be used to match the requested RR owner name and type

      Intermediate label names are used to prove no wildcard matches the
      requested name.  Intermediate label names are formed from type, so proving
      that the requested RR's fully qualified domain name by removing the
      rightmost labels from the name.  For example,
      "www.a.b.c.example.com." has intermediate names of
      "a.b.c.example.com", "b.c.example.com", "c.example.com",
      "example.com", and "com".  To prove RRset does not exist also requires proving that
      no possible wildcard matches, exists which could have been used to generate
      a positive response.

   To prove non-existence of an RRset, the resolver MUST start with must be able to
   verify both that the longest intermediate label name prove
      that:

         No wildcard exists at this intermediate label name.  In other
         words, there is an authenticated queried RRset does not exist and that no
   relevant wildcard RRset exists.  Proving this may require more than
   one NXT RR such RRset from the NXT RR's owner
         name logically appears before "*.intermediate_label_name" and zone.  If the complete set of necessary NXT RR's Next Domain field appears logically after
         "*.intermediate_lable_name".

      The
   RRsets is not present in a response (perhaps due to truncation), then
   a security-aware resolver MUST continue testing intermediate label names until
      (in resend the query in order of decreasing label count) until to attempt
   to obtain the intermediate label
      name matches an authenticated full collection of NXT RR's owner name.  Note that this
      is guaranteed RRs necessary to occur since at some point verify non-
   existence of the intermediate label
      will equal requested RRset.   As with all DNS operations,
   however, the zone name and NXT RR exists at resolver MUST bound the zone name.

   4.4 work it puts into answering any
   particular query.

5.4 Example

   4.4.1

5.4.1 Example of Re-Constructing the Original Owner Name

   Suppose the that a security-aware resolver receives a response containing
   an answer RRset with an owner name received in a response of is
      "www.a.b.c.example.com.". "www.a.b.c.example.com".
   This fully qualified domain name has 6 labels: "www", "a", "b", "c",
   "example", and "com".   The  What name
      used in the resolver should use when
   reconstructing the original signed data depends on the value of the
   SIG Labels. RR's Labels field.

   If the value of the SIG RR's Labels field is 6, then the SIG RR's
   Labels field equals matches the number of labels in the RRsets fully qualified domain name.
      Wildcard expansion was not used to construct owner name, and the
   resolver should assume that this RRset and is not the result of wildcard
   expansion.  The resolver should therefore use "www.a.b.c.example.com"
   as the owner name "www.a.b.c.example.com." is used to construct when reconstructing the original signed data. data for
   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 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 SIG RR's Labels field is 3, then the SIG Labels field is
      strictly less than number of labels in the RRset's fully qualified
      domain name.  Wildcard expansion was used to construct this RRset
      and resolver
   should reconstruct the original wildcard owner name is constructed by appending prepending "*." to the
   last 3 labels in of the owner name.  The name
      "*.c.example.com." is is used to construct 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 SIG RR's Labels field is greater than 6, then
   this SIG RR cannot possibly be valid for the answer RRset, 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 "www.example.com", starting from a an
   initial root key key.

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

6. IANA Considerations

   This document introduces no IANA considerations.

      [9]

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

   6.

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

7. Security Considerations

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

   At this time, at least two substantial elements of the DNSSEC
   specification have yet to be decided by the working group.  The open
   opt-in issue would change elements such as what RRsets must be
   signed, would impact how wildcards are used, and would replace
   authenticated denial of existence with authenticated denial of
   security.   The ad-bit  Handling of the AD bit is also undecided.  The ad AD bit (as
   currently defined) is used to indicate the security status of RRsets
   in the response.  These items clearly raise security considerations
   and will be addressed here as these issues are resolved in the
   working group.

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

   7.

   Please see [9] 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

   [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 in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [5]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
         RFC 2181, July 1997.

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

   [7]  Eastlake,   Conrad, D., "DNS Request and Transaction Signatures (
           SIG(0)s)", "Indicating Resolver Support of DNSSEC", RFC 2931, September 2000. 3225,
         December 2001.

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

   [9]   Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNSSEC
           Intro", October 2002.

      [9]
         "DNS Security Introduction and Requirements", draft-ietf-
         dnsext-dnssec-intro-05 (work in progress), February 2003.

   [10]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
         "Resource Records for the DNS Security Extensions", October 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 (work in progress), February 2003.

Informative References

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

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

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

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

Authors' Addresses

   Roy Arends
   Bankastraat 41-E
   1094 EB Amsterdam
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   EMail: roy@logmess.com 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
      RR set
   RRset that proves no wildcard expansion matches N.  The algorithm was
   written for clarity clarity, not efficiency: (EDITORS NOTE:  the
      algorithm was really written on a redeye flight during dull movie
      so it is unlikely to really achieve clarity :)

         0. INPUT: a name (N) and a zone (Z).
            INIT: NXT_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 for N.
               Return all RRsets associated with N
            Else
               Add the name that would immediately
               preceed
               precede N in S to NXT_SET.
            EndIf

         3. Replace the leftmost label of N with *

         4. If N exists in S
               There is a positive wildcard match for N.
               Return all RRsets associated with N
            Else
               Add the NXT for name that would immediately
               preceed
               precede N in S to NXT_SET.
            EndIf

         5. Remove the leading * from N.

         6. If N exists in S
               There is an a name that terminates the wildcard search.
               Add the NXT for N to NXT_SET and return NXT_SET.
            Else
               Goto Step 3
            EndIf

         Note: the algorithm is guaranteed to terminate since
               eventually there will be a match or N will be
               reduced to zone name itself and the zone name
               must exist in S.

Full Copyright Statement

   Copyright (C) The Internet Society (2002). (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.

   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.