[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4035

DNS Extensions                                                 R. Arends
Internet-Draft
Expires: April 25, 2003                                        M. Larson
                                                                VeriSign
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                        October 25, 2002


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

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, 2003.

Copyright Notice

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

Abstract

      This document is part of a family of documents that describe the
      DNS Security Extensions (DNSSEC).  The DNS Security Extensions are
      a collection of new resource records and protocol modifications
      that provide source authentication for the DNS.  This document
      describes the DNSSEC protocol modifications.  The concept of zone



Arends, et al.           Expires April 25, 2003                 [Page 1]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      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
      the appropriate KEY, SIG, NXT, and DS resource records.  These
      resource records are used by the resolver to authenticate the
      response.

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

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Background and Related Documents . . . . . . . . . . . . . .  4
   1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3   Editors Notes  . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.1 Open Technical Issues  . . . . . . . . . . . . . . . . . . .  4
   1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . .  5
   1.3.3 Typos and Minor Corrections  . . . . . . . . . . . . . . . .  5
   2.    Zone Signing and Zone Format . . . . . . . . . . . . . . . .  6
   2.1   Inclusion of KEY RRs in a Zone . . . . . . . . . . . . . . .  7
   2.2   Inclusion of NXT RRs in a Zone . . . . . . . . . . . . . . .  7
   2.3   Inclusion of SIG RRs in a Zone . . . . . . . . . . . . . . .  7
   2.4   Changes to the CNAME Resource Record.  . . . . . . . . . . .  8
   2.5   Inclusion of DS RRs in a Zone  . . . . . . . . . . . . . . .  8
   2.6   Example of a Secure Zone . . . . . . . . . . . . . . . . . .  9
   3.    Constructing DNS Responses . . . . . . . . . . . . . . . . . 10
   3.1   Indicating Resolver Support for DNSSEC . . . . . . . . . . . 10
   3.2   Inclusion of SIG RRs in a Response . . . . . . . . . . . . . 11
   3.3   Inclusion of KEY RRs In a Response . . . . . . . . . . . . . 12
   3.4   Inclusion of NXT RRs In a Response . . . . . . . . . . . . . 12
   3.4.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12
   3.4.2 Case 2: Query Name Does Not Exist and No Wildcard Matches  . 13
   3.4.3 Case 3: Query Name Does Not Exist, but Wildcard Matches  . . 13
   3.5   Inclusion of DS RRs In a Response  . . . . . . . . . . . . . 13
   3.6   Responding to Queries for DS RRs . . . . . . . . . . . . . . 13
   3.7   Special Considerations for Recursive/Caching Servers . . . . 15
   3.8   Setting the AD and CD Bits in a Response . . . . . . . . . . 15
   3.9   Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16
   4.    Authenticating DNS Responses . . . . . . . . . . . . . . . . 17
   4.1   Authenticating Referrals . . . . . . . . . . . . . . . . . . 18
   4.2   Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 19
   4.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 19
   4.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 20
   4.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 22
   4.2.4 Authenticating Wildcard Expanded RRset . . . . . . . . . . . 23
   4.3   Authenticated Denial of Existence  . . . . . . . . . . . . . 23
   4.4   Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 24



Arends, et al.           Expires April 25, 2003                 [Page 2]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   4.4.1 Example of Re-Constructing the Original Name . . . . . . . . 24
   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 26
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 27
   7.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
         References . . . . . . . . . . . . . . . . . . . . . . . . . 29
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
   A.    Algorithm For Handling Wildcard Expansion  . . . . . . . . . 31
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 32











































Arends, et al.           Expires April 25, 2003                 [Page 3]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   1. Introduction

      The DNS Security Extensions (DNSSEC) modify several aspects of the
      DNS protocol.  The concept of 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 the resolver has indicated
      support for DNSSEC, the process of constructing a DNS response is
      also modified to include the appropriate KEY, SIG, NXT, and DS RR
      types.  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
      to handle queries for the DS RR type.  Finally, Section 4 defines
      how a resolver uses the DNSSEC RRs to authenticate a response.

   1.1 Background and Related Documents

      This document is part of a family of documents that define the DNS
      security extensions.  The DNS security extensions (DNSSEC) are a
      collection of resource records and DNS protocol modifications that
      add source authentication the Domain Name System (DNS).  An
      introduction to DNSSEC and definition of common terms can be found
      in [8].  A definition of the DNSSEC resource records can be found
      in [9].  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].

   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 Notes

   1.3.1 Open Technical Issues

      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 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 of the AD bit is described in section 3.8 and requires
      input from the working group.  Since the AD bit usage is not



Arends, et al.           Expires April 25, 2003                 [Page 4]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      resolved, this text attempts to capture current ideas and drafts,
      but further input from the working group is required.

   1.3.2 Technical Changes or Corrections

      Please report technical corrections to dnssec-
      editors@east.isi.edu.  To assist the editors, please indicate the
      text in error and point out the RFC that defines the correct
      behavior.  For a technical change where there is no RFC that
      defines the correct behavior (or RFCs provide conflicting
      answers), please post the issue to namedroppers.

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

   1.3.3 Typos and Minor Corrections

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

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
























Arends, et al.           Expires April 25, 2003                 [Page 5]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   2. Zone Signing and Zone Format

      DNSSEC defines a new process called zone signing and adds the KEY,
      SIG, NXT, and DS resource records to the zone format.  The zone
      signing process is the first step in enabling resource record
      authentication for this zone.  After a signed zone has been
      created and loaded, the KEY, SIG, NXT, and DS resource records can
      be included in responses (as decribed in Section 3) and can be
      used by resolvers to authenticate responses (as describe in
      Section 4).  KEY, SIG, NXT, and DS RRs MUST NOT appear in unsigned
      zones.

      To sign a zone, the zone administrator generates one or more
      public/private key pairs.  The zone's public key(s) are made
      available by storing them in KEY resource records.  Other DNS
      public keys, such as public keys used by TKEY and SIG(0), can also
      be stored in KEY RRs.  Once the KEY records have been added to the
      zone, the zone is sorted into a canonical form and NXT resource
      records are added to enable authenticated denial of existence.
      The zone administrator then signs every authoritative RRset in the
      zone using the private key(s) and the signatures are stored in SIG
      resource records.  The resulting signed zone contains all data in
      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 the KEY, NXT, and SIG resource records in a zone
      (respectively).

      The zone signing process also requires a change in the definition
      of the CNAME resource record and Section 2.4 changes the CNAME RR
      to allow SIG and NXT RRs 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 associated with the RRset's owner
      name MUST also be updated.  In addition, the zone MUST be
      periodically resigned 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.






Arends, et al.           Expires April 25, 2003                 [Page 6]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   2.1 Inclusion of KEY RRs in a Zone

      A zone administrator generates a set of public/private key pairs
      and uses the private key(s) to sign authoritative RRsets in the
      zone.  For each private zone key used to create SIG RRs, there
      SHOULD be a corresponding public KEY RR stored at the zone apex
      and the corresponding KEY RR MUST have the Zone Key Flag (KEY
      RDATA Flag bit 7) set to 1.  KEY RR's with Zone Flag set MUST only
      appear at the zone apex.

      A signed zone MUST have at least one zone KEY RR in its apex KEY
      set 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 MUST be at least
      one SIG record that meets all of the following requirements:

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

         The SIG class is equal to the RRset class.

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

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

         The SIG Labels field is equal to the number of labels in RRset



Arends, et al.           Expires April 25, 2003                 [Page 7]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


         owner name.

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

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

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

      The SIG RR itself MUST NOT be signed since signing a SIG RRset
      adds no value and creates a unterminated dependency loop in the
      signing process.

      The NS RRset that appears at the zone apex name MUST be signed,
      but NS RRsets that appear at delegation owner names (child zones)
      MUST NOT be signed and any glue address RRsets assoicated with
      child delegations MUST NOT be signed.

   2.4 Changes to the CNAME Resource Record.

      If a CNAME RR is present at a name, RRs other than the SIG and NXT
      MUST NOT be present at that name.

      The above is modification to the original CNAME definition given
      in [1].  The original definition of CNAME did not allow any other
      resource records to co-exist with a CNAME record, but the zone
      signing process associates NXT and SIG resource records with every
      authorititative name.  To resolve this conflict, the definition of
      the CNAME resource record is modified to allow for the co-
      existence of NXT and SIG RRs.

   2.5 Inclusion of DS RRs in a Zone

      The DS resource record is used to establish authentication chains
      between DNS zones.  A signed delegation (child zone) SHOULD
      provide its parent zone with a DS RR for the delegation.  All DS
      RRsets stored in a zone MUST be signedx and DS RRsets MUST NOT
      appear at non-delegation points or at a zone's apex.

      The DS RR provided by the child SHOULD point to a KEY RR that is
      present in the child's apex KEY set 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.




Arends, et al.           Expires April 25, 2003                 [Page 8]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      Note that the process of providing a DS RR can be accomplished by
      either directly sending the DS RR to the parent or by sending a
      KEY RR to the parent and requesting that the parent construct a DS
      RR for the given KEY RR.  The parent/child communication needs to
      be authenticated in order to prevent an adversary from inserting a
      false DS RR.  DNSSEC operational and best practices documents are
      encouraged to provide guidelines for providing a DS RR.

   2.6 Example of a Secure Zone

            secure zone

      The apex KEY set includes two KEY 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 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 this KEY and might be used by
      SIG(0) to authenticate transactions from this host.

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

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






















Arends, et al.           Expires April 25, 2003                 [Page 9]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   3. Constructing DNS Responses

      Unless a resolver has indicated support for DNSSEC, no changes are
      made to the standard (non-secure) DNS response and a server simply
      behaves as if no DNSSEC RR types were present.  This helps avoid
      backwards compatability issues and also avoids increasing the size
      of (non-secure) DNS responses.  Servers MUST NOT include any
      DNSSEC RR types (KEY NXT SIG DS) unless the resolver has indicated
      support for DNSSEC using one of the mechanisms described in
      Section 3.1.

      If a resolver has indicated support for DNSSEC:

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

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

         DS RRs (or an NXT RR if DS RRs are present) are automatically
         included in referals according to the rules in Section 3.5.

         Since the DS RR is the only RR type that appears only on the
         upper side of a delegation, any query for the DS RR type
         requires special processing as described in Section 3.6.

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

   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



Arends, et al.           Expires April 25, 2003                [Page 10]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      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 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 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 the resolver has indicated support for DNSSEC, servers SHOULD
      attempt to send SIG RRs that can be used to authenticate the RR
      sets in the response.  The inclusion of SIG RRs in a response is
      subject to the following rules:

         When an signed RRset is placed in the answer section, its SIG
         RRs are also placed in the answer 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.

         When an signed RRset is placed in the authority section, its
         SIG RRs are also placed in the 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.

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








Arends, et al.           Expires April 25, 2003                [Page 11]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   3.3 Inclusion of KEY RRs In a Response

      If the resolver has indicated support for DNSSEC and the query
      requests the SOA or NS RRs, then a server SHOULD return the KEY
      RRset with the same name in the additional section.  If not all
      additional information will fit in the response, type A and AAAA
      glue RRs have higher priority than KEY RRs.  The SIG RR(s)
      associated with the KEY RR set SHOULD also be included in the
      additional section (see including SIG RRs in Section 3.2).

   3.4 Inclusion of NXT RRs In a Response

      If the resolver has indicated support for DNSSEC, the server MUST
      include NXT RRs in each of the following cases:

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

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

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

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

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

   3.4.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 section.  Any SIG(s) associated with
      the NXT RRset are also included in the authority section (see
      including SIG RRs in Section 3.2) If space does not permit the
      inclusion of the NXT RR (or its associate SIG RRs), the response
      MUST be considered truncated.

      Note that since the query name exists, an 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.




Arends, et al.           Expires April 25, 2003                [Page 12]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


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

      If the query name does not exist and no wildcard expansion matches
      the query, the authority section of the response MUST include an
      NXT RR that proves there was  no exact match for the name and MUST
      also include NXT RRs that prove no wildcard would have matched the
      query.  Any SIG(s) associated with the NXT RRsets are also
      included in the authority section (see including SIG RRs in
      Section 3.2)  If space does not permit the inclusion of these NXT
      RRs, the response MUST be considered truncated.

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

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

      If the query name does not exist and a wildcard expansion matches
      the query, then the wildcard card expanded answer (and any SIG RRs
      associated with the wildcard RR) are returned in the answer
      section.   The authority section of the response MUST include NXT
      RRs that prove there were no exact matches for the name and MUST
      also include NXT RRs to prove no closer wildcard entry would have
      matched this query.

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

   3.5 Inclusion of DS RRs In a Response

      If the resolver has indicated support for DNSSEC, a server
      returning a referral for the delegation MUST include both the NS
      RRset and DS RRset if the DS RRset exists.  The NS RRset MUST be
      placed before the DS RRset (and its assoicated SIG RRs).

      If the resolver has indicated support for DNSSEC, a server
      returning a referral for the delegation MUST include both parent
      NS RRset and the parent NXT RR if the DS RRset does not exist.
      The NS RRset MUST be placed before the NXT RRset (and its
      assoicated SIG RRs).

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

   3.6 Responding to Queries for DS RRs

      The DS record is the first resource record that appears only on



Arends, et al.           Expires April 25, 2003                [Page 13]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      the upper side of a delegation.  In other words, the DS record for
      zone "example.com" is only stored in the "com" zone (the parent/
      upper side of the delegation).  This introduces novel server
      behavior since the child server is authoritative for the zone, but
      the zone does not contain the DS RR.  A server's response to a DS
      query depends on whether the server is authoritative for the
      parent and/or child zones as described below.

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

      If the server is authoritative for the child zone at a delegation
      point and is not authoritative for the parent zone, there is no
      natural response.  The child zone is not authoritative for the DS
      record at the zone's apex and the DS RR is only stored at the
      parent.

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

         If the server does not perform recursion to find the DS RR,
         the 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 server answers as if it is
      authoritative for the zone and the DS record does not exist.  Note
      DS-aware recursive servers will query the parent zone at
      delegation points and thus will not be affected by this behavior.

      For example, suppose "example.com" is a delegation point and a
      query for the "example.com" DS RRset is received by a server.

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

         If the server is authoritative for "example.com" and is not
         authortative for "com",  the server MAY perform recursion to
         find the "example.com" DS record (provided the RD bit was set



Arends, et al.           Expires April 25, 2003                [Page 14]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


         in the query).  If the server does not use recursion to obtain
         the DS RR, the 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 for Recursive/Caching Servers

      A DNSSEC aware recursive server MUST set the DO bit on recursive
      requests, regardless of the status of the DO bit on the initiating
      resolver request.  If the initiating resolver request does not
      have the DO bit set, the recursive DNSSEC-aware server MUST remove
      any DNSSEC security RRs before returning the data to the client,
      however cached data MUST NOT be modified.

      A caching server SHOULD NOT attempt to answer a query by piecing
      together the responses it has received previous from other queries
      that requested different names or RR types.  A cache typically
      does not have access to the complete zone and thus it can be
      difficult for a caching server to determine the proper SIG, NXT,
      KEY, and DS RRs for a given a query.  A caching server SHOULD
      cache each response single atomic entry indexed by the question
      (including the response and the all the assoicated DNSSEC RR
      types).  The cache SHOULD discard the entire entry when any RR in
      the response expires.

   3.8 Setting the AD and CD Bits in a Response

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

      The CD bit is set by the resolver and MUST be copied in the
      response.  If the CD bit is set to one, it indicates the resolver
      is willing to perform authentication and the server need not
      perform authentication on the RRsets in the response.

      Regardless of the CD bit, the server MAY choose to perform
      authentication (or choose not to perform authentication) according
      to the local server policy.  The CD bit MAY be used in
      constructing the local server policy.  If local 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).



Arends, et al.           Expires April 25, 2003                [Page 15]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      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 be set on a response
      unless all of the RRsets in the answer and authority sections have
      met the servers local authentication policy.  A resolver MUST NOT
      use the AD bit unless unless it communicates with the server over
      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)
































Arends, et al.           Expires April 25, 2003                [Page 16]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   4. Authenticating DNS Responses

      In order to use DNSSEC RRs for authentication, a resolver requires
      some intial 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
      remainder of this section assumes the resolver has used some
      unspecified off-line mechanism and 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

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

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

      Once 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 down
      the DNS tree to obtain other apex KEY RRsets.  If the resolver was
      initially configured with a root KEY RR and if every delegation
      had a DS RR assoicated with it, the resolver could obtain any apex
      KEY RRset.  The process of using DS RRs to authentic a referal is
      described in Section 4.1.

      Once a zones apex KEY RRset has been authenticated, Section 4.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 shows how the resolver can use authenticated
      NXT RRsets from the zone to prove an RRset is not present in the
      zone.

      If the resolver has indicated support for DNSSEC, DNSSEC aware
      servers SHOULD attempt to provide the necessary KEY, SIG, NXT, and
      DS RRets in a response (see Section 3).  However, a response that
      lacks the approriate DNSSEC RRs may result from configuration
      issues such as a non-DNSSEC aware cache that removes or fails
      request DNSSEC RRs or may result from an intentional attack where



Arends, et al.           Expires April 25, 2003                [Page 17]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      an adversary forges a response, strips DNSSEC RRs from a response
      forges, or modifies the query so DNSSEC RRs appear not to be
      requested.  The absence of DNSSEC data in response MUST NOT be
      taken to mean that no authentication information is available.

      A resolver SHOULD expect authentication information from signed
      zones.  A SHOULD believe a zone is signed if the resolver has been
      configured with public key information for the zone or if the
      zone's parent is signed and the delegation at 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 Authenticating Referrals

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

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

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

         The Algorithm, Key Tag, and Digest fields in the DS RR match
         the algorithm, key tag, and digest of a KEY RR present in the
         child's apex KEY RRset.

         The matching KEY RR in the child zone has the Zone Flag bit set
         to one, the corresponding private key has signed the child apex
         KEY RRset, and the resulting SIG RR authenticates the child's
         apex KEY RRset.

      If the referal from the parent zone did not contain a DS RRset,
      the response SHOULD have included an NXT RRset that proves no DS
      RRset exists for the delegation name (see Section 3.5).  A



Arends, et al.           Expires April 25, 2003                [Page 18]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      resolver SHOULD send the parent a query for the DS RRset if
      neither a DS RRset or NXT RRset is included in the referal.

      If the resolver authenticates an NXT RRset that proves 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 belongs to the child zone (or any delegation
      below the child zone), this initial KEY RR MAY be used to 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 for a signed delegation there are two NXT RRs associated with
      the delegation name.  One NXT RR resides at the parent can be used
      to prove whether a DS RRset exists for the delegation name.  A
      second NXT RR resides at the child zone and identifies which
      RRsets are present at the apex in the child zone.  The parent NXT
      RR and child NXT RR can always be distinguished since the only the
      child NXT RR will specify an SOA RR set exists at the name.  A
      resolver MUST only use the parent NXT RR when proving a DS RRset
      does not exist.

   4.2 Authenticating an RRSet Using a SIG RR

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

   4.2.1 Checking the SIG RR Validity

      An SIG RR can be used to authenicate an RRset if all of the
      following conditions hold:

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

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

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

         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.



Arends, et al.           Expires April 25, 2003                [Page 19]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


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

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

         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.

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

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

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

         The apex KEY RRset containing the KEY RR is considered
         authentic

         The RRset covered by the SIG RR is the apex KEY RRset itself
         and the KEY RR matches an authenticated DS RR from the parent
         zone or matches some initial KEY RR/DS RR that is known to be
         authentic.


   4.2.2 Reconstructing the Signed Data

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

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

            "|" denotes append




Arends, et al.           Expires April 25, 2003                [Page 20]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


            SIG_RDATA is the wire format of the SIG RDATA fields with
               the Signature field excluded.
               the Signer's Name in cannonical 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 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 example of original name calculation is given in Section 4.4.1.
      The canonical form for names and RRsets is defined in [9].

      NXT RRsets present at a delegaion name require special processing.
      There are two distinct NXT RRsets associated with a signed
      delegation name.  One NXT RRset resides at the parent and
      specifies which RRset are present at the parent.  A second NXT
      RRset resides at the child 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 exists at the name.  When



Arends, et al.           Expires April 25, 2003                [Page 21]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      constructing the original NXT RRset, the NXT RRs MUST NOT be
      combined with NXT RRs from the child (and vice versa).

   4.2.3 Checking the Signature

      Once the SIG RR has met the validity requirements described in
      Section 4.2.1 and the original signed data has been reconstructed
      as described in Section 4.2.2, the cryptographic signature is used
      to authenticate the signed data (and thus authenticate the RRset).

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

      Note it is possible that more than one KEY RR matches the
      conditions in Section 4.2.1.  In this case, the resolver can not
      determine which KEY RR is used to authenticate the signature and
      the resolver MUST try each matching KEY RR until the resolver has
      either validated the signature or all matching KEY RRs have
      failed.

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

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

         the RR TTL received in the response

         the value in the SIG RRs Original TTL field






Arends, et al.           Expires April 25, 2003                [Page 22]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   4.2.4 Authenticating Wildcard Expanded RRset

      If a SIG RR's fully qualified domain name does not equal the
      Labels field in the SIG RDATA, then SIG RR (and its covered RRset)
      were created as a result of wildcard expansion.  Once the
      signature has been verified 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 the wildcard)

         the name "*.intermediate_label_name" does not exist (otherwise
         this wildcard would take precedence)

      Note the response SHOULD include all NXT RRs needed to the
      authenticate the response (see Section Section 3.4).

   4.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 automatically
      included in the response, provided the zone is signed and the
      resolver has indicated support for DNSSEC.  NXT RRsets are
      authenticated according to standard RRset authentication rules
      described in Section 4.2 and are applied as follows:

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

      If the requested RR name logically appears after an authenticated
      NXT RR owner name and logically appears before the name listed in



Arends, et al.           Expires April 25, 2003                [Page 23]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      that NXT RR's Next Domain Name field, then the requested RR name
      is not present in the zone.  However, it is possible 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 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 no wildcard matches, the
      resolver MUST start with the longest intermediate label name prove
      that:

         No wildcard exists at this intermediate label name.  In other
         words, there is an authenticated NXT RR such the NXT RR's owner
         name logically appears before "*.intermediate_label_name" and
         the NXT RR's Next Domain field appears logically after
         "*.intermediate_lable_name".

      The resolver MUST continue testing intermediate label names until
      (in order of decreasing label count) until the intermediate label
      name matches an authenticated NXT RR's owner name.  Note that this
      is guaranteed to occur since at some point the intermediate label
      will equal the zone name and NXT RR exists at the zone name.

   4.4 Example

   4.4.1 Example of Re-Constructing the Original Name

      Suppose the RRset owner name received in a response is
      "www.a.b.c.example.com.".  This fully qualified domain name has 6
      labels: "www", "a", "b", "c", "example", and "com".   The name
      used in reconstructing the original signed data depends on the
      value of the SIG Labels.

      If the SIG Labels field is 6, then the SIG Labels field equals the
      number of labels in the RRsets fully qualified domain name.
      Wildcard expansion was not used to construct this RRset and the
      name "www.a.b.c.example.com." is used to construct the original
      signed data.

      If the SIG 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 the original wildcard owner name is constructed by appending
      "*." to the last 3 labels in the owner name.  The name
      "*.c.example.com." is is used to construct the original signed



Arends, et al.           Expires April 25, 2003                [Page 24]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


      data.

      authentication process for www.example.com starting from a initial
      root key

      authentication process for non-existent www.a.b.c.example.com
      starting from a initial root key












































Arends, et al.           Expires April 25, 2003                [Page 25]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   5. IANA Considerations

      This document introduces no IANA considerations.

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













































Arends, et al.           Expires April 25, 2003                [Page 26]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   6. 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 is also undecided.  The 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 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 version of the
      security considerations.































Arends, et al.           Expires April 25, 2003                [Page 27]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


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












































Arends, et al.           Expires April 25, 2003                [Page 28]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


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, D., "DNS Request and Transaction Signatures (
           SIG(0)s)", RFC 2931, September 2000.

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

      [9]  Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
           Records for the DNS Security Extensions", October 2002.


Authors' Addresses

   Roy Arends
   Bankastraat 41-E
   1094 EB Amsterdam
   NL

   EMail: roy@logmess.com


   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: mlarson@verisign.com




Arends, et al.           Expires April 25, 2003                [Page 29]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   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



































Arends, et al.           Expires April 25, 2003                [Page 30]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


   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 that proves no wildcard expansion matches N.  The algorithm
      was written for 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 N in S to NXT_SET.
            EndIf

         3. Replace the leftmost label of N with *

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

         5. Remove the leading * from N.

         6. If N exists in S
               There is an 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.





Arends, et al.           Expires April 25, 2003                [Page 31]

Internet-Draft       DNSSEC Protocol Modifications          October 2002


Full Copyright Statement

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



















Arends, et al.           Expires April 25, 2003                [Page 32]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/