path: root/doc/rfc/rfc5155.txt

Network Working Group                                          B. Laurie
Request for Comments: 5155                                     G. Sisson
Category: Standards Track                                      R. Arends
                                                                 Nominet
                                                               D. Blacka
                                                          VeriSign, Inc.
                                                              March 2008


     DNS Security (DNSSEC) Hashed Authenticated Denial of Existence

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Domain Name System Security (DNSSEC) Extensions introduced the
   NSEC resource record (RR) for authenticated denial of existence.
   This document introduces an alternative resource record, NSEC3, which
   similarly provides authenticated denial of existence.  However, it
   also provides measures against zone enumeration and permits gradual
   expansion of delegation-centric zones.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . .  6
   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  7
     3.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . .  8
       3.1.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . .  8
       3.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.6.  Hash Length  . . . . . . . . . . . . . . . . . . . . .  9
       3.1.7.  Next Hashed Owner Name . . . . . . . . . . . . . . . .  9
       3.1.8.  Type Bit Maps  . . . . . . . . . . . . . . . . . . . .  9
     3.2.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  9
       3.2.1.  Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
     3.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 11



Laurie, et al.              Standards Track                     [Page 1]

RFC 5155                         NSEC3                        March 2008


   4.  The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
     4.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
       4.1.2.  Flag Fields  . . . . . . . . . . . . . . . . . . . . . 12
       4.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . . 13
       4.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
     4.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 14
   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 14
   6.  Opt-Out  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Authoritative Server Considerations  . . . . . . . . . . . . . 16
     7.1.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
     7.2.  Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
       7.2.1.  Closest Encloser Proof . . . . . . . . . . . . . . . . 18
       7.2.2.  Name Error Responses . . . . . . . . . . . . . . . . . 19
       7.2.3.  No Data Responses, QTYPE is not DS . . . . . . . . . . 19
       7.2.4.  No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
       7.2.5.  Wildcard No Data Responses . . . . . . . . . . . . . . 19
       7.2.6.  Wildcard Answer Responses  . . . . . . . . . . . . . . 20
       7.2.7.  Referrals to Unsigned Subzones . . . . . . . . . . . . 20
       7.2.8.  Responding to Queries for NSEC3 Owner Names  . . . . . 20
       7.2.9.  Server Response to a Run-Time Collision  . . . . . . . 21
     7.3.  Secondary Servers  . . . . . . . . . . . . . . . . . . . . 21
     7.4.  Zones Using Unknown Hash Algorithms  . . . . . . . . . . . 21
     7.5.  Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Validator Considerations . . . . . . . . . . . . . . . . . . . 23
     8.1.  Responses with Unknown Hash Types  . . . . . . . . . . . . 23
     8.2.  Verifying NSEC3 RRs  . . . . . . . . . . . . . . . . . . . 23
     8.3.  Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
     8.4.  Validating Name Error Responses  . . . . . . . . . . . . . 24
     8.5.  Validating No Data Responses, QTYPE is not DS  . . . . . . 24
     8.6.  Validating No Data Responses, QTYPE is DS  . . . . . . . . 24
     8.7.  Validating Wildcard No Data Responses  . . . . . . . . . . 25
     8.8.  Validating Wildcard Answer Responses . . . . . . . . . . . 25
     8.9.  Validating Referrals to Unsigned Subzones  . . . . . . . . 25
   9.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 26
     9.1.  NSEC3 Resource Record Caching  . . . . . . . . . . . . . . 26
     9.2.  Use of the AD Bit  . . . . . . . . . . . . . . . . . . . . 26
   10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
     10.1. Domain Name Length Restrictions  . . . . . . . . . . . . . 26
     10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
     10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
     10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
     10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
     12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30



Laurie, et al.              Standards Track                     [Page 2]

RFC 5155                         NSEC3                        March 2008


       12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
       12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
       12.1.3. Transitioning to a New Hash Algorithm  . . . . . . . . 31
       12.1.4. Using High Iteration Values  . . . . . . . . . . . . . 31
     12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
     12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     13.2. Informative References . . . . . . . . . . . . . . . . . . 34
   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 35
   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 40
     B.1.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
     B.2.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 42
       B.2.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 43
     B.3.  Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
     B.4.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
     B.5.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
     B.6.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 48
   Appendix C.  Special Considerations  . . . . . . . . . . . . . . . 48
     C.1.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 49
     C.2.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
       C.2.1.  Avoiding Hash Collisions During Generation . . . . . . 50
       C.2.2.  Second Preimage Requirement Analysis . . . . . . . . . 50




























Laurie, et al.              Standards Track                     [Page 3]

RFC 5155                         NSEC3                        March 2008


1.  Introduction

1.1.  Rationale

   The DNS Security Extensions included the NSEC RR to provide
   authenticated denial of existence.  Though the NSEC RR meets the
   requirements for authenticated denial of existence, it introduces a
   side-effect in that the contents of a zone can be enumerated.  This
   property introduces undesired policy issues.

   The enumeration is enabled by the set of NSEC records that exists
   inside a signed zone.  An NSEC record lists two names that are
   ordered canonically, in order to show that nothing exists between the
   two names.  The complete set of NSEC records lists all the names in a
   zone.  It is trivial to enumerate the content of a zone by querying
   for names that do not exist.

   An enumerated zone can be used, for example, as a source of probable
   e-mail addresses for spam, or as a key for multiple WHOIS queries to
   reveal registrant data that many registries may have legal
   obligations to protect.  Many registries therefore prohibit the
   copying of their zone data; however, the use of NSEC RRs renders
   these policies unenforceable.

   A second problem is that the cost to cryptographically secure
   delegations to unsigned zones is high, relative to the perceived
   security benefit, in two cases: large, delegation-centric zones, and
   zones where insecure delegations will be updated rapidly.  In these
   cases, the costs of maintaining the NSEC RR chain may be extremely
   high and use of the "Opt-Out" convention may be more appropriate (for
   these unsecured zones).

   This document presents the NSEC3 Resource Record which can be used as
   an alternative to NSEC to mitigate these issues.

   Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
   and [DNSEXT-NSEC2v2].

1.2.  Requirements

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








Laurie, et al.              Standards Track                     [Page 4]

RFC 5155                         NSEC3                        March 2008


1.3.  Terminology

   The reader is assumed to be familiar with the basic DNS and DNSSEC
   concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
   [RFC4035], and subsequent RFCs that update them: [RFC2136],
   [RFC2181], and [RFC2308].

   The following terminology is used throughout this document:

   Zone enumeration:  the practice of discovering the full content of a
      zone via successive queries.  Zone enumeration was non-trivial
      prior to the introduction of DNSSEC.

   Original owner name:  the owner name corresponding to a hashed owner
      name.

   Hashed owner name:  the owner name created after applying the hash
      function to an owner name.

   Hash order:  the order in which hashed owner names are arranged
      according to their numerical value, treating the leftmost (lowest
      numbered) octet as the most significant octet.  Note that this
      order is the same as the canonical DNS name order specified in
      [RFC4034], when the hashed owner names are in base32, encoded with
      an Extended Hex Alphabet [RFC4648].

   Empty non-terminal:  a domain name that owns no resource records, but
      has one or more subdomains that do.

   Delegation:  an NS RRSet with a name different from the current zone
      apex (non-zone-apex), signifying a delegation to a child zone.

   Secure delegation:  a name containing a delegation (NS RRSet) and a
      signed DS RRSet, signifying a delegation to a signed child zone.

   Insecure delegation:  a name containing a delegation (NS RRSet), but
      lacking a DS RRSet, signifying a delegation to an unsigned child
      zone.

   Opt-Out NSEC3 resource record:  an NSEC3 resource record that has the
      Opt-Out flag set to 1.

   Opt-Out zone:  a zone with at least one Opt-Out NSEC3 RR.

   Closest encloser:  the longest existing ancestor of a name.  See also
      Section 3.3.1 of [RFC4592].





Laurie, et al.              Standards Track                     [Page 5]

RFC 5155                         NSEC3                        March 2008


   Closest provable encloser:  the longest ancestor of a name that can
      be proven to exist.  Note that this is only different from the
      closest encloser in an Opt-Out zone.

   Next closer name:  the name one label longer than the closest
      provable encloser of a name.

   Base32:  the "Base 32 Encoding with Extended Hex Alphabet" as
      specified in [RFC4648].  Note that trailing padding characters
      ("=") are not used in the NSEC3 specification.

   To cover:  An NSEC3 RR is said to "cover" a name if the hash of the
      name or "next closer" name falls between the owner name and the
      next hashed owner name of the NSEC3.  In other words, if it proves
      the nonexistence of the name, either directly or by proving the
      nonexistence of an ancestor of the name.

   To match:  An NSEC3 RR is said to "match" a name if the owner name of
      the NSEC3 RR is the same as the hashed owner name of that name.

2.  Backwards Compatibility

   This specification describes a protocol change that is not generally
   backwards compatible with [RFC4033], [RFC4034], and [RFC4035].  In
   particular, security-aware resolvers that are unaware of this
   specification (NSEC3-unaware resolvers) may fail to validate the
   responses introduced by this document.

   In order to aid deployment, this specification uses a signaling
   technique to prevent NSEC3-unaware resolvers from attempting to
   validate responses from NSEC3-signed zones.

   This specification allocates two new DNSKEY algorithm identifiers for
   this purpose.  Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
   3, DSA.  Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
   RSASHA1.  These are not new algorithms, they are additional
   identifiers for the existing algorithms.

   Zones signed according to this specification MUST only use these
   algorithm identifiers for their DNSKEY RRs.  Because these new
   identifiers will be unknown algorithms to existing, NSEC3-unaware
   resolvers, those resolvers will then treat responses from the NSEC3
   signed zone as insecure, as detailed in Section 5.2 of [RFC4035].

   These algorithm identifiers are used with the NSEC3 hash algorithm
   SHA1.  Using other NSEC3 hash algorithms requires allocation of a new
   alias (see Section 12.1.3).




Laurie, et al.              Standards Track                     [Page 6]

RFC 5155                         NSEC3                        March 2008


   Security aware resolvers that are aware of this specification MUST
   recognize the new algorithm identifiers and treat them as equivalent
   to the algorithms that they alias.

   A methodology for transitioning from a DNSSEC signed zone to a zone
   signed using NSEC3 is discussed in Section 10.4.

3.  The NSEC3 Resource Record

   The NSEC3 Resource Record (RR) provides authenticated denial of
   existence for DNS Resource Record Sets.

   The NSEC3 RR lists RR types present at the original owner name of the
   NSEC3 RR.  It includes the next hashed owner name in the hash order
   of the zone.  The complete set of NSEC3 RRs in a zone indicates which
   RRSets exist for the original owner name of the RR and form a chain
   of hashed owner names in the zone.  This information is used to
   provide authenticated denial of existence for DNS data.  To provide
   protection against zone enumeration, the owner names used in the
   NSEC3 RR are cryptographic hashes of the original owner name
   prepended as a single label to the name of the zone.  The NSEC3 RR
   indicates which hash function is used to construct the hash, which
   salt is used, and how many iterations of the hash function are
   performed over the original owner name.  The hashing technique is
   described fully in Section 5.

   Hashed owner names of unsigned delegations may be excluded from the
   chain.  An NSEC3 RR whose span covers the hash of an owner name or
   "next closer" name of an unsigned delegation is referred to as an
   Opt-Out NSEC3 RR and is indicated by the presence of a flag.

   The owner name for the NSEC3 RR is the base32 encoding of the hashed
   owner name prepended as a single label to the name of the zone.

   The type value for the NSEC3 RR is 50.

   The NSEC3 RR RDATA format is class independent and is described
   below.

   The class MUST be the same as the class of the original owner name.

   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
   field.  This is in the spirit of negative caching [RFC2308].








Laurie, et al.              Standards Track                     [Page 7]

RFC 5155                         NSEC3                        March 2008


3.1.  RDATA Fields

3.1.1.  Hash Algorithm

   The Hash Algorithm field identifies the cryptographic hash algorithm
   used to construct the hash-value.

   The values for this field are defined in the NSEC3 hash algorithm
   registry defined in Section 11.

3.1.2.  Flags

   The Flags field contains 8 one-bit flags that can be used to indicate
   different processing.  All undefined flags must be zero.  The only
   flag defined by this specification is the Opt-Out flag.

3.1.2.1.  Opt-Out Flag

   If the Opt-Out flag is set, the NSEC3 record covers zero or more
   unsigned delegations.

   If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
   delegations.

   The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
   delegations.  It is the least significant bit in the Flags field.
   See Section 6 for details about the use of this flag.

3.1.3.  Iterations

   The Iterations field defines the number of additional times the hash
   function has been performed.  More iterations result in greater
   resiliency of the hash value against dictionary attacks, but at a
   higher computational cost for both the server and resolver.  See
   Section 5 for details of the use of this field, and Section 10.3 for
   limitations on the value.

3.1.4.  Salt Length

   The Salt Length field defines the length of the Salt field in octets,
   ranging in value from 0 to 255.

3.1.5.  Salt

   The Salt field is appended to the original owner name before hashing
   in order to defend against pre-calculated dictionary attacks.  See
   Section 5 for details on how the salt is used.




Laurie, et al.              Standards Track                     [Page 8]

RFC 5155                         NSEC3                        March 2008


3.1.6.  Hash Length

   The Hash Length field defines the length of the Next Hashed Owner
   Name field, ranging in value from 1 to 255 octets.

3.1.7.  Next Hashed Owner Name

   The Next Hashed Owner Name field contains the next hashed owner name
   in hash order.  This value is in binary format.  Given the ordered
   set of all hashed owner names, the Next Hashed Owner Name field
   contains the hash of an owner name that immediately follows the owner
   name of the given NSEC3 RR.  The value of the Next Hashed Owner Name
   field in the last NSEC3 RR in the zone is the same as the hashed
   owner name of the first NSEC3 RR in the zone in hash order.  Note
   that, unlike the owner name of the NSEC3 RR, the value of this field
   does not contain the appended zone name.

3.1.8.  Type Bit Maps

   The Type Bit Maps field identifies the RRSet types that exist at the
   original owner name of the NSEC3 RR.

3.2.  NSEC3 RDATA Wire Format

   The RDATA of the NSEC3 RR is as shown below:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hash Alg.   |     Flags     |          Iterations           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Salt Length  |                     Salt                      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Hash Length  |             Next Hashed Owner Name            /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                         Type Bit Maps                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hash Algorithm is a single octet.

   Flags field is a single octet, the Opt-Out flag is the least
   significant bit, as shown below:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |             |O|
   +-+-+-+-+-+-+-+-+




Laurie, et al.              Standards Track                     [Page 9]

RFC 5155                         NSEC3                        March 2008


   Iterations is represented as a 16-bit unsigned integer, with the most
   significant bit first.

   Salt Length is represented as an unsigned octet.  Salt Length
   represents the length of the Salt field in octets.  If the value is
   zero, the following Salt field is omitted.

   Salt, if present, is encoded as a sequence of binary octets.  The
   length of this field is determined by the preceding Salt Length
   field.

   Hash Length is represented as an unsigned octet.  Hash Length
   represents the length of the Next Hashed Owner Name field in octets.

   The next hashed owner name is not base32 encoded, unlike the owner
   name of the NSEC3 RR.  It is the unmodified binary hash value.  It
   does not include the name of the containing zone.  The length of this
   field is determined by the preceding Hash Length field.

3.2.1.  Type Bit Maps Encoding

   The encoding of the Type Bit Maps field is the same as that used by
   the NSEC RR, described in [RFC4034].  It is explained and clarified
   here for clarity.

   The RR type space is split into 256 window blocks, each representing
   the low-order 8 bits of the 16-bit RR type space.  Each block that
   has at least one active RR type is encoded using a single octet
   window number (from 0 to 255), a single octet bitmap length (from 1
   to 32) indicating the number of octets used for the bitmap of the
   window block, and up to 32 octets (256 bits) of bitmap.

   Blocks are present in the NSEC3 RR RDATA in increasing numerical
   order.

      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

      where "|" denotes concatenation.

   Each bitmap encodes the low-order 8 bits of RR types within the
   window block, in network bit order.  The first bit is bit 0.  For
   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
   to RR type 2 (NS), and so forth.  For window block 1, bit 1
   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
   1, it indicates that an RRSet of that type is present for the
   original owner name of the NSEC3 RR.  If a bit is set to 0, it
   indicates that no RRSet of that type is present for the original
   owner name of the NSEC3 RR.



Laurie, et al.              Standards Track                    [Page 10]

RFC 5155                         NSEC3                        March 2008


   Since bit 0 in window block 0 refers to the non-existing RR type 0,
   it MUST be set to 0.  After verification, the validator MUST ignore
   the value of bit 0 in window block 0.

   Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
   [RFC2929] or within the range reserved for assignment only to QTYPEs
   and Meta-TYPEs MUST be set to 0, since they do not appear in zone
   data.  If encountered, they must be ignored upon reading.

   Blocks with no types present MUST NOT be included.  Trailing zero
   octets in the bitmap MUST be omitted.  The length of the bitmap of
   each block is determined by the type code with the largest numerical
   value, within that block, among the set of RR types present at the
   original owner name of the NSEC3 RR.  Trailing octets not specified
   MUST be interpreted as zero octets.

3.3.  Presentation Format

   The presentation format of the RDATA portion is as follows:

   o  The Hash Algorithm field is represented as an unsigned decimal
      integer.  The value has a maximum of 255.

   o  The Flags field is represented as an unsigned decimal integer.
      The value has a maximum of 255.

   o  The Iterations field is represented as an unsigned decimal
      integer.  The value is between 0 and 65535, inclusive.

   o  The Salt Length field is not represented.

   o  The Salt field is represented as a sequence of case-insensitive
      hexadecimal digits.  Whitespace is not allowed within the
      sequence.  The Salt field is represented as "-" (without the
      quotes) when the Salt Length field has a value of 0.

   o  The Hash Length field is not represented.

   o  The Next Hashed Owner Name field is represented as an unpadded
      sequence of case-insensitive base32 digits, without whitespace.

   o  The Type Bit Maps field is represented as a sequence of RR type
      mnemonics.  When the mnemonic is not known, the TYPE
      representation as described in Section 5 of [RFC3597] MUST be
      used.






Laurie, et al.              Standards Track                    [Page 11]

RFC 5155                         NSEC3                        March 2008


4.  The NSEC3PARAM Resource Record

   The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
   flags, iterations, and salt) needed by authoritative servers to
   calculate hashed owner names.  The presence of an NSEC3PARAM RR at a
   zone apex indicates that the specified parameters may be used by
   authoritative servers to choose an appropriate set of NSEC3 RRs for
   negative responses.  The NSEC3PARAM RR is not used by validators or
   resolvers.

   If an NSEC3PARAM RR is present at the apex of a zone with a Flags
   field value of zero, then there MUST be an NSEC3 RR using the same
   hash algorithm, iterations, and salt parameters present at every
   hashed owner name in the zone.  That is, the zone MUST contain a
   complete set of NSEC3 RRs with the same hash algorithm, iterations,
   and salt parameters.

   The owner name for the NSEC3PARAM RR is the name of the zone apex.

   The type value for the NSEC3PARAM RR is 51.

   The NSEC3PARAM RR RDATA format is class independent and is described
   below.

   The class MUST be the same as the NSEC3 RRs to which this RR refers.

4.1.  RDATA Fields

   The RDATA for this RR mirrors the first four fields in the NSEC3 RR.

4.1.1.  Hash Algorithm

   The Hash Algorithm field identifies the cryptographic hash algorithm
   used to construct the hash-value.

   The acceptable values are the same as the corresponding field in the
   NSEC3 RR.

4.1.2.  Flag Fields

   The Opt-Out flag is not used and is set to zero.

   All other flags are reserved for future use, and must be zero.

   NSEC3PARAM RRs with a Flags field value other than zero MUST be
   ignored.





Laurie, et al.              Standards Track                    [Page 12]

RFC 5155                         NSEC3                        March 2008


4.1.3.  Iterations

   The Iterations field defines the number of additional times the hash
   is performed.

   Its acceptable values are the same as the corresponding field in the
   NSEC3 RR.

4.1.4.  Salt Length

   The Salt Length field defines the length of the salt in octets,
   ranging in value from 0 to 255.

4.1.5.  Salt

   The Salt field is appended to the original owner name before hashing.

4.2.  NSEC3PARAM RDATA Wire Format

   The RDATA of the NSEC3PARAM RR is as shown below:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hash Alg.   |     Flags     |          Iterations           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Salt Length  |                     Salt                      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hash Algorithm is a single octet.

   Flags field is a single octet.

   Iterations is represented as a 16-bit unsigned integer, with the most
   significant bit first.

   Salt Length is represented as an unsigned octet.  Salt Length
   represents the length of the following Salt field in octets.  If the
   value is zero, the Salt field is omitted.

   Salt, if present, is encoded as a sequence of binary octets.  The
   length of this field is determined by the preceding Salt Length
   field.








Laurie, et al.              Standards Track                    [Page 13]

RFC 5155                         NSEC3                        March 2008


4.3.  Presentation Format

   The presentation format of the RDATA portion is as follows:

   o  The Hash Algorithm field is represented as an unsigned decimal
      integer.  The value has a maximum of 255.

   o  The Flags field is represented as an unsigned decimal integer.
      The value has a maximum value of 255.

   o  The Iterations field is represented as an unsigned decimal
      integer.  The value is between 0 and 65535, inclusive.

   o  The Salt Length field is not represented.

   o  The Salt field is represented as a sequence of case-insensitive
      hexadecimal digits.  Whitespace is not allowed within the
      sequence.  This field is represented as "-" (without the quotes)
      when the Salt Length field is zero.

5.  Calculation of the Hash

   The hash calculation uses three of the NSEC3 RDATA fields: Hash
   Algorithm, Salt, and Iterations.

   Define H(x) to be the hash of x using the Hash Algorithm selected by
   the NSEC3 RR, k to be the number of Iterations, and || to indicate
   concatenation.  Then define:

      IH(salt, x, 0) = H(x || salt), and

      IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0

   Then the calculated hash of an owner name is

      IH(salt, owner name, iterations),

   where the owner name is in the canonical form, defined as:

   The wire format of the owner name where:

   1.  The owner name is fully expanded (no DNS name compression) and
       fully qualified;

   2.  All uppercase US-ASCII letters are replaced by the corresponding
       lowercase US-ASCII letters;





Laurie, et al.              Standards Track                    [Page 14]

RFC 5155                         NSEC3                        March 2008


   3.  If the owner name is a wildcard name, the owner name is in its
       original unexpanded form, including the "*" label (no wildcard
       substitution);

   This form is as defined in Section 6.2 of [RFC4034].

   The method to calculate the Hash is based on [RFC2898].

6.  Opt-Out

   In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
   RRSets at delegation points are not signed and may be accompanied by
   a DS RRSet.  With the Opt-Out bit clear, the security status of the
   child zone is determined by the presence or absence of this DS RRSet,
   cryptographically proven by the signed NSEC3 RR at the hashed owner
   name of the delegation.  Setting the Opt-Out flag modifies this by
   allowing insecure delegations to exist within the signed zone without
   a corresponding NSEC3 RR at the hashed owner name of the delegation.

   An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
   owner name or "next closer" name of the delegation is between the
   owner name of the NSEC3 RR and the next hashed owner name.

   An Opt-Out NSEC3 RR does not assert the existence or non-existence of
   the insecure delegations that it may cover.  This allows for the
   addition or removal of these delegations without recalculating or re-
   signing RRs in the NSEC3 RR chain.  However, Opt-Out NSEC3 RRs do
   assert the (non)existence of other, authoritative RRSets.

   An Opt-Out NSEC3 RR MAY have the same original owner name as an
   insecure delegation.  In this case, the delegation is proven insecure
   by the lack of a DS bit in the type map and the signed NSEC3 RR does
   assert the existence of the delegation.

   Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
   non-Opt-Out NSEC3 RRs.  If an NSEC3 RR is not Opt-Out, there MUST NOT
   be any hashed owner names of insecure delegations (nor any other RRs)
   between it and the name indicated by the next hashed owner name in
   the NSEC3 RDATA.  If it is Opt-Out, it MUST only cover hashed owner
   names or hashed "next closer" names of insecure delegations.

   The effects of the Opt-Out flag on signing, serving, and validating
   responses are covered in following sections.








Laurie, et al.              Standards Track                    [Page 15]

RFC 5155                         NSEC3                        March 2008


7.  Authoritative Server Considerations

7.1.  Zone Signing

   Zones using NSEC3 must satisfy the following properties:

   o  Each owner name within the zone that owns authoritative RRSets
      MUST have a corresponding NSEC3 RR.  Owner names that correspond
      to unsigned delegations MAY have a corresponding NSEC3 RR.
      However, if there is not a corresponding NSEC3 RR, there MUST be
      an Opt-Out NSEC3 RR that covers the "next closer" name to the
      delegation.  Other non-authoritative RRs are not represented by
      NSEC3 RRs.

   o  Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
      the empty non-terminal is only derived from an insecure delegation
      covered by an Opt-Out NSEC3 RR.

   o  The TTL value for any NSEC3 RR SHOULD be the same as the minimum
      TTL value field in the zone SOA RR.

   o  The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
      indicate the presence of all types present at the original owner
      name, except for the types solely contributed by an NSEC3 RR
      itself.  Note that this means that the NSEC3 type itself will
      never be present in the Type Bit Maps.

   The following steps describe a method of proper construction of NSEC3
   RRs.  This is not the only such possible method.

   1.  Select the hash algorithm and the values for salt and iterations.

   2.  For each unique original owner name in the zone add an NSEC3 RR.

       *  If Opt-Out is being used, owner names of unsigned delegations
          MAY be excluded.

       *  The owner name of the NSEC3 RR is the hash of the original
          owner name, prepended as a single label to the zone name.

       *  The Next Hashed Owner Name field is left blank for the moment.

       *  If Opt-Out is being used, set the Opt-Out bit to one.

       *  For collision detection purposes, optionally keep track of the
          original owner name with the NSEC3 RR.





Laurie, et al.              Standards Track                    [Page 16]

RFC 5155                         NSEC3                        March 2008


       *  Additionally, for collision detection purposes, optionally
          create an additional NSEC3 RR corresponding to the original
          owner name with the asterisk label prepended (i.e., as if a
          wildcard existed as a child of this owner name) and keep track
          of this original owner name.  Mark this NSEC3 RR as temporary.

   3.  For each RRSet at the original owner name, set the corresponding
       bit in the Type Bit Maps field.

   4.  If the difference in number of labels between the apex and the
       original owner name is greater than 1, additional NSEC3 RRs need
       to be added for every empty non-terminal between the apex and the
       original owner name.  This process may generate NSEC3 RRs with
       duplicate hashed owner names.  Optionally, for collision
       detection, track the original owner names of these NSEC3 RRs and
       create temporary NSEC3 RRs for wildcard collisions in a similar
       fashion to step 1.

   5.  Sort the set of NSEC3 RRs into hash order.

   6.  Combine NSEC3 RRs with identical hashed owner names by replacing
       them with a single NSEC3 RR with the Type Bit Maps field
       consisting of the union of the types represented by the set of
       NSEC3 RRs.  If the original owner name was tracked, then
       collisions may be detected when combining, as all of the matching
       NSEC3 RRs should have the same original owner name.  Discard any
       possible temporary NSEC3 RRs.

   7.  In each NSEC3 RR, insert the next hashed owner name by using the
       value of the next NSEC3 RR in hash order.  The next hashed owner
       name of the last NSEC3 RR in the zone contains the value of the
       hashed owner name of the first NSEC3 RR in the hash order.

   8.  Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
       Iterations, and Salt fields to the zone apex.

   If a hash collision is detected, then a new salt has to be chosen,
   and the signing process restarted.

7.2.  Zone Serving

   This specification modifies DNSSEC-enabled DNS responses generated by
   authoritative servers.  In particular, it replaces the use of NSEC
   RRs in such responses with NSEC3 RRs.







Laurie, et al.              Standards Track                    [Page 17]

RFC 5155                         NSEC3                        March 2008


   In the following response cases, the NSEC RRs dictated by DNSSEC
   [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
   Responses that would not contain NSEC RRs are unchanged by this
   specification.

   When returning responses containing multiple NSEC3 RRs, all of the
   NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
   values.  The Flags field value MUST be either zero or one.

7.2.1.  Closest Encloser Proof

   For many NSEC3 responses a proof of the closest encloser is required.
   This is a proof that some ancestor of the QNAME is the closest
   encloser of QNAME.

   This proof consists of (up to) two different NSEC3 RRs:

   o  An NSEC3 RR that matches the closest (provable) encloser.

   o  An NSEC3 RR that covers the "next closer" name to the closest
      encloser.

   The first NSEC3 RR essentially proposes a possible closest encloser,
   and proves that the particular encloser does, in fact, exist.  The
   second NSEC3 RR proves that the possible closest encloser is the
   closest, and proves that the QNAME (and any ancestors between QNAME
   and the closest encloser) does not exist.

   These NSEC3 RRs are collectively referred to as the "closest encloser
   proof" in the subsequent descriptions.

   For example, the closest encloser proof for the nonexistent
   "alpha.beta.gamma.example." owner name might prove that
   "gamma.example." is the closest encloser.  This response would
   contain the NSEC3 RR that matches "gamma.example.", and would also
   contain the NSEC3 RR that covers "beta.gamma.example." (which is the
   "next closer" name).

   It is possible, when using Opt-Out (Section 6), to not be able to
   prove the actual closest encloser because it is, or is part of an
   insecure delegation covered by an Opt-Out span.  In this case,
   instead of proving the actual closest encloser, the closest provable
   encloser is used.  That is, the closest enclosing authoritative name
   is used instead.  In this case, the set of NSEC3 RRs used for this
   proof is referred to as the "closest provable encloser proof".






Laurie, et al.              Standards Track                    [Page 18]

RFC 5155                         NSEC3                        March 2008


7.2.2.  Name Error Responses

   To prove the nonexistence of QNAME, a closest encloser proof and an
   NSEC3 RR covering the (nonexistent) wildcard RR at the closest
   encloser MUST be included in the response.  This collection of (up
   to) three NSEC3 RRs proves both that QNAME does not exist and that a
   wildcard that could have matched QNAME also does not exist.

   For example, if "gamma.example." is the closest provable encloser to
   QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
   the authority section of the response.

7.2.3.  No Data Responses, QTYPE is not DS

   The server MUST include the NSEC3 RR that matches QNAME.  This NSEC3
   RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
   set in its Type Bit Maps field.

7.2.4.  No Data Responses, QTYPE is DS

   If there is an NSEC3 RR that matches QNAME, the server MUST return it
   in the response.  The bits corresponding with DS and CNAME MUST NOT
   be set in the Type Bit Maps field of this NSEC3 RR.

   If no NSEC3 RR matches QNAME, the server MUST return a closest
   provable encloser proof for QNAME.  The NSEC3 RR that covers the
   "next closer" name MUST have the Opt-Out bit set (note that this is
   true by definition -- if the Opt-Out bit is not set, something has
   gone wrong).

   If a server is authoritative for both sides of a zone cut at QNAME,
   the server MUST return the proof from the parent side of the zone
   cut.

7.2.5.  Wildcard No Data Responses

   If there is a wildcard match for QNAME, but QTYPE is not present at
   that name, the response MUST include a closest encloser proof for
   QNAME and MUST include the NSEC3 RR that matches the wildcard.  This
   combination proves both that QNAME itself does not exist and that a
   wildcard that matches QNAME does exist.  Note that the closest
   encloser to QNAME MUST be the immediate ancestor of the wildcard RR
   (if this is not the case, then something has gone wrong).








Laurie, et al.              Standards Track                    [Page 19]

RFC 5155                         NSEC3                        March 2008


7.2.6.  Wildcard Answer Responses

   If there is a wildcard match for QNAME and QTYPE, then, in addition
   to the expanded wildcard RRSet returned in the answer section of the
   response, proof that the wildcard match was valid must be returned.

   This proof is accomplished by proving that both QNAME does not exist
   and that the closest encloser of the QNAME and the immediate ancestor
   of the wildcard are the same (i.e., the correct wildcard matched).

   To this end, the NSEC3 RR that covers the "next closer" name of the
   immediate ancestor of the wildcard MUST be returned.  It is not
   necessary to return an NSEC3 RR that matches the closest encloser, as
   the existence of this closest encloser is proven by the presence of
   the expanded wildcard in the response.

7.2.7.  Referrals to Unsigned Subzones

   If there is an NSEC3 RR that matches the delegation name, then that
   NSEC3 RR MUST be included in the response.  The DS bit in the type
   bit maps of the NSEC3 RR MUST NOT be set.

   If the zone is Opt-Out, then there may not be an NSEC3 RR
   corresponding to the delegation.  In this case, the closest provable
   encloser proof MUST be included in the response.  The included NSEC3
   RR that covers the "next closer" name for the delegation MUST have
   the Opt-Out flag set to one.  (Note that this will be the case unless
   something has gone wrong).

7.2.8.  Responding to Queries for NSEC3 Owner Names

   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
   chain like other owner names.  As a result, each NSEC3 owner name is
   covered by another NSEC3 RR, effectively negating the existence of
   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
   can be proven by its RRSIG RRSet.

   If the following conditions are all true:

   o  the QNAME equals the owner name of an existing NSEC3 RR, and

   o  no RR types exist at the QNAME, nor at any descendant of QNAME,

   then the response MUST be constructed as a Name Error response
   (Section 7.2.2).  Or, in other words, the authoritative name server
   will act as if the owner name of the NSEC3 RR did not exist.





Laurie, et al.              Standards Track                    [Page 20]

RFC 5155                         NSEC3                        March 2008


   Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
   query.

7.2.9.  Server Response to a Run-Time Collision

   If the hash of a non-existing QNAME collides with the owner name of
   an existing NSEC3 RR, then the server will be unable to return a
   response that proves that QNAME does not exist.  In this case, the
   server MUST return a response with an RCODE of 2 (server failure).

   Note that with the hash algorithm specified in this document, SHA-1,
   such collisions are highly unlikely.

7.3.  Secondary Servers

   Secondary servers (and perhaps other entities) need to reliably
   determine which NSEC3 parameters (i.e., hash, salt, and iterations)
   are present at every hashed owner name, in order to be able to choose
   an appropriate set of NSEC3 RRs for negative responses.  This is
   indicated by an NSEC3PARAM RR present at the zone apex.

   If there are multiple NSEC3PARAM RRs present, there are multiple
   valid NSEC3 chains present.  The server must choose one of them, but
   may use any criteria to do so.

7.4.  Zones Using Unknown Hash Algorithms

   Zones that are signed according to this specification, but are using
   an unrecognized NSEC3 hash algorithm value, cannot be effectively
   served.  Such zones SHOULD be rejected when loading.  Servers SHOULD
   respond with RCODE=2 (server failure) responses when handling queries
   that would fall under such zones.

7.5.  Dynamic Update

   A zone signed using NSEC3 may accept dynamic updates [RFC2136].
   However, NSEC3 introduces some special considerations for dynamic
   updates.

   Adding and removing names in a zone MUST account for the creation or
   removal of empty non-terminals.

   o  When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
      corresponding to empty non-terminals created by that name MUST be
      removed.  Note that more than one name may be asserting the
      existence of a particular empty non-terminal.





Laurie, et al.              Standards Track                    [Page 21]

RFC 5155                         NSEC3                        March 2008


   o  When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
      MUST also be added for any empty non-terminals that are created.
      That is, if there is not an existing NSEC3 RR matching an empty
      non-terminal, it must be created and added.

   The presence of Opt-Out in a zone means that some additions or
   delegations of names will not require changes to the NSEC3 RRs in a
   zone.

   o  When removing a delegation RRSet, if that delegation does not have
      a matching NSEC3 RR, then it was opted out.  In this case, nothing
      further needs to be done.

   o  When adding a delegation RRSet, if the "next closer" name of the
      delegation is covered by an existing Opt-Out NSEC3 RR, then the
      delegation MAY be added without modifying the NSEC3 RRs in the
      zone.

   The presence of Opt-Out in a zone means that when adding or removing
   NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
   modified NSEC3 RRs is ambiguous.  Servers SHOULD follow this set of
   basic rules to resolve the ambiguity.

   The central concept to these rules is that the state of the Opt-Out
   flag of the covering NSEC3 RR is preserved.

   o  When removing an NSEC3 RR, the value of the Opt-Out flag for the
      previous NSEC3 RR (the one whose next hashed owner name is
      modified) should not be changed.

   o  When adding an NSEC3 RR, the value of the Opt-Out flag is set to
      the value of the Opt-Out flag of the NSEC3 RR that previously
      covered the owner name of the NSEC3 RR.  That is, the now previous
      NSEC3 RR.

   If the zone in question is consistent with its use of the Opt-Out
   flag (that is, all NSEC3 RRs in the zone have the same value for the
   flag) then these rules will retain that consistency.  If the zone is
   not consistent in the use of the flag (i.e., a partially Opt-Out
   zone), then these rules will not retain the same pattern of use of
   the Opt-Out flag.

   For zones that partially use the Opt-Out flag, if there is a logical
   pattern for that use, the pattern could be maintained by using a
   local policy on the server.






Laurie, et al.              Standards Track                    [Page 22]

RFC 5155                         NSEC3                        March 2008


8.  Validator Considerations

8.1.  Responses with Unknown Hash Types

   A validator MUST ignore NSEC3 RRs with unknown hash types.  The
   practical result of this is that responses containing only such NSEC3
   RRs will generally be considered bogus.

8.2.  Verifying NSEC3 RRs

   A validator MUST ignore NSEC3 RRs with a Flag fields value other than
   zero or one.

   A validator MAY treat a response as bogus if the response contains
   NSEC3 RRs that contain different values for hash algorithm,
   iterations, or salt from each other for that zone.

8.3.  Closest Encloser Proof

   In order to verify a closest encloser proof, the validator MUST find
   the longest name, X, such that

   o  X is an ancestor of QNAME that is matched by an NSEC3 RR present
      in the response.  This is a candidate for the closest encloser,
      and

   o  The name one label longer than X (but still an ancestor of -- or
      equal to -- QNAME) is covered by an NSEC3 RR present in the
      response.

   One possible algorithm for verifying this proof is as follows:

   1.  Set SNAME=QNAME.  Clear the flag.

   2.  Check whether SNAME exists:

       *  If there is no NSEC3 RR in the response that matches SNAME
          (i.e., an NSEC3 RR whose owner name is the same as the hash of
          SNAME, prepended as a single label to the zone name), clear
          the flag.

       *  If there is an NSEC3 RR in the response that covers SNAME, set
          the flag.

       *  If there is a matching NSEC3 RR in the response and the flag
          was set, then the proof is complete, and SNAME is the closest
          encloser.




Laurie, et al.              Standards Track                    [Page 23]

RFC 5155                         NSEC3                        March 2008


       *  If there is a matching NSEC3 RR in the response, but the flag
          is not set, then the response is bogus.

   3.  Truncate SNAME by one label from the left, go to step 2.

   Once the closest encloser has been discovered, the validator MUST
   check that the NSEC3 RR that has the closest encloser as the original
   owner name is from the proper zone.  The DNAME type bit must not be
   set and the NS type bit may only be set if the SOA type bit is set.
   If this is not the case, it would be an indication that an attacker
   is using them to falsely deny the existence of RRs for which the
   server is not authoritative.

   In the following descriptions, the phrase "a closest (provable)
   encloser proof for X" means that the algorithm above (or an
   equivalent algorithm) proves that X does not exist by proving that an
   ancestor of X is its closest encloser.

8.4.  Validating Name Error Responses

   A validator MUST verify that there is a closest encloser proof for
   QNAME present in the response and that there is an NSEC3 RR that
   covers the wildcard at the closest encloser (i.e., the name formed by
   prepending the asterisk label to the closest encloser).

8.5.  Validating No Data Responses, QTYPE is not DS

   The validator MUST verify that an NSEC3 RR that matches QNAME is
   present and that both the QTYPE and the CNAME type are not set in its
   Type Bit Maps field.

   Note that this test also covers the case where the NSEC3 RR exists
   because it corresponds to an empty non-terminal, in which case the
   NSEC3 RR will have an empty Type Bit Maps field.

8.6.  Validating No Data Responses, QTYPE is DS

   If there is an NSEC3 RR that matches QNAME present in the response,
   then that NSEC3 RR MUST NOT have the bits corresponding to DS and
   CNAME set in its Type Bit Maps field.

   If there is no such NSEC3 RR, then the validator MUST verify that a
   closest provable encloser proof for QNAME is present in the response,
   and that the NSEC3 RR that covers the "next closer" name has the Opt-
   Out bit set.






Laurie, et al.              Standards Track                    [Page 24]

RFC 5155                         NSEC3                        March 2008


8.7.  Validating Wildcard No Data Responses

   The validator MUST verify a closest encloser proof for QNAME and MUST
   find an NSEC3 RR present in the response that matches the wildcard
   name generated by prepending the asterisk label to the closest
   encloser.  Furthermore, the bits corresponding to both QTYPE and
   CNAME MUST NOT be set in the wildcard matching NSEC3 RR.

8.8.  Validating Wildcard Answer Responses

   The verified wildcard answer RRSet in the response provides the
   validator with a (candidate) closest encloser for QNAME.  This
   closest encloser is the immediate ancestor to the generating
   wildcard.

   Validators MUST verify that there is an NSEC3 RR that covers the
   "next closer" name to QNAME present in the response.  This proves
   that QNAME itself did not exist and that the correct wildcard was
   used to generate the response.

8.9.  Validating Referrals to Unsigned Subzones

   The delegation name in a referral is the owner name of the NS RRSet
   present in the authority section of the referral response.

   If there is an NSEC3 RR present in the response that matches the
   delegation name, then the validator MUST ensure that the NS bit is
   set and that the DS bit is not set in the Type Bit Maps field of the
   NSEC3 RR.  The validator MUST also ensure that the NSEC3 RR is from
   the correct (i.e., parent) zone.  This is done by ensuring that the
   SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.

   Note that the presence of an NS bit implies the absence of a DNAME
   bit, so there is no need to check for the DNAME bit in the Type Bit
   Maps field of the NSEC3 RR.

   If there is no NSEC3 RR present that matches the delegation name,
   then the validator MUST verify a closest provable encloser proof for
   the delegation name.  The validator MUST verify that the Opt-Out bit
   is set in the NSEC3 RR that covers the "next closer" name to the
   delegation name.










Laurie, et al.              Standards Track                    [Page 25]

RFC 5155                         NSEC3                        March 2008


9.  Resolver Considerations

9.1.  NSEC3 Resource Record Caching

   Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
   when returning responses that contain them.  In DNSSEC [RFC4035], in
   many cases it is possible to find the correct NSEC RR to return in a
   response by name (e.g., when returning a referral, the NSEC RR will
   always have the same owner name as the delegation).  With this
   specification, that will not be true, nor will a cache be able to
   calculate the name(s) of the appropriate NSEC3 RR(s).
   Implementations may need to use new methods for caching and
   retrieving NSEC3 RRs.

9.2.  Use of the AD Bit

   The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
   response containing a closest (provable) encloser proof in which the
   NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.

   This rule is based on what this closest encloser proof actually
   proves: names that would be covered by the Opt-Out NSEC3 RR may or
   may not exist as insecure delegations.  As such, not all the data in
   responses containing such closest encloser proofs will have been
   cryptographically verified, so the AD bit cannot be set.

10.  Special Considerations

10.1.  Domain Name Length Restrictions

   Zones signed using this specification have additional domain name
   length restrictions imposed upon them.  In particular, zones with
   names that, when converted into hashed owner names exceed the 255
   octet length limit imposed by [RFC1035], cannot use this
   specification.

   The actual maximum length of a domain name in a particular zone
   depends on both the length of the zone name (versus the whole domain
   name) and the particular hash function used.

   As an example, SHA-1 produces a hash of 160 bits.  The base-32
   encoding of 160 bits results in 32 characters.  The 32 characters are
   prepended to the name of the zone as a single label, which includes a
   length field of a single octet.  The maximum length of the zone name,
   when using SHA-1, is 222 octets (255 - 33).






Laurie, et al.              Standards Track                    [Page 26]

RFC 5155                         NSEC3                        March 2008


10.2.  DNAME at the Zone Apex

   The DNAME specification in Section 3 of [RFC2672] has a 'no-
   descendants' limitation.  If a DNAME RR is present at node N, there
   MUST be no data at any descendant of N.

   If N is the apex of the zone, there will be NSEC3 and RRSIG types
   present at descendants of N.  This specification updates the DNAME
   specification to allow NSEC3 and RRSIG types at descendants of the
   apex regardless of the existence of DNAME at the apex.

10.3.  Iterations

   Setting the number of iterations used allows the zone owner to choose
   the cost of computing a hash, and therefore the cost of generating a
   dictionary.  Note that this is distinct from the effect of salt,
   which prevents the use of a single precomputed dictionary for all
   time.

   Obviously the number of iterations also affects the zone owner's cost
   of signing and serving the zone as well as the validator's cost of
   verifying responses from the zone.  We therefore impose an upper
   limit on the number of iterations.  We base this on the number of
   iterations that approximates the cost of verifying an RRSet.

   The limits, therefore, are based on the size of the smallest zone
   signing key, rounded up to the nearest table value (or rounded down
   if the key is larger than the largest table value).

   A zone owner MUST NOT use a value higher than shown in the table
   below for iterations for the given key size.  A resolver MAY treat a
   response with a higher value as insecure, after the validator has
   verified that the signature over the NSEC3 RR is correct.

                         +----------+------------+
                         | Key Size | Iterations |
                         +----------+------------+
                         | 1024     | 150        |
                         | 2048     | 500        |
                         | 4096     | 2,500      |
                         +----------+------------+

   This table is based on an approximation of the ratio between the cost
   of an SHA-1 calculation and the cost of an RSA verification for keys
   of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
   (2500 to 1).





Laurie, et al.              Standards Track                    [Page 27]

RFC 5155                         NSEC3                        March 2008


   The ratio between SHA-1 calculation and DSA verification is higher
   (1500 to 1 for keys of size 1024).  A higher iteration count degrades
   performance, while DSA verification is already more expensive than
   RSA for the same key size.  Therefore the values in the table MUST be
   used independent of the key algorithm.

10.4.  Transitioning a Signed Zone from NSEC to NSEC3

   When transitioning an already signed and trusted zone to this
   specification, care must be taken to prevent client validation
   failures during the process.

   The basic procedure is as follows:

   1.  Transition all DNSKEYs to DNSKEYs using the algorithm aliases
       described in Section 2.  The actual method for safely and
       securely changing the DNSKEY RRSet of the zone is outside the
       scope of this specification.  However, the end result MUST be
       that all DS RRs in the parent use the specified algorithm
       aliases.

       After this transition is complete, all NSEC3-unaware clients will
       treat the zone as insecure.  At this point, the authoritative
       server still returns negative and wildcard responses that contain
       NSEC RRs.

   2.  Add signed NSEC3 RRs to the zone, either incrementally or all at
       once.  If adding incrementally, then the last RRSet added MUST be
       the NSEC3PARAM RRSet.

   3.  Upon the addition of the NSEC3PARAM RRSet, the server switches to
       serving negative and wildcard responses with NSEC3 RRs according
       to this specification.

   4.  Remove the NSEC RRs either incrementally or all at once.

10.5.  Transitioning a Signed Zone from NSEC3 to NSEC

   To safely transition back to a DNSSEC [RFC4035] signed zone, simply
   reverse the procedure above:

   1.  Add NSEC RRs incrementally or all at once.

   2.  Remove the NSEC3PARAM RRSet.  This will signal the server to use
       the NSEC RRs for negative and wildcard responses.

   3.  Remove the NSEC3 RRs either incrementally or all at once.




Laurie, et al.              Standards Track                    [Page 28]

RFC 5155                         NSEC3                        March 2008


   4.  Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
       After this transition is complete, all NSEC3-unaware clients will
       treat the zone as secure.

11.  IANA Considerations

   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
   parameter, this document does not define a particular mechanism for
   safely transitioning from one NSEC3 hash algorithm to another.  When
   specifying a new hash algorithm for use with NSEC3, a transition
   mechanism MUST also be defined.

   This document updates the IANA registry "DOMAIN NAME SYSTEM
   PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
   registry "TYPES", by defining two new types.  Section 3 defines the
   NSEC3 RR type 50.  Section 4 defines the NSEC3PARAM RR type 51.

   This document updates the IANA registry "DNS SECURITY ALGORITHM
   NUMBERS -- per [RFC4035]"
   (http://www.iana.org/assignments/dns-sec-alg-numbers).  Section 2
   defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
   respectively existing registrations DSA and RSASHA1 in combination
   with NSEC3 hash algorithm SHA1.

   Since these algorithm numbers are aliases for existing DNSKEY
   algorithm numbers, the flags that exist for the original algorithm
   are valid for the alias algorithm.

   This document creates a new IANA registry for NSEC3 flags.  This
   registry is named "DNSSEC NSEC3 Flags".  The initial contents of this
   registry are:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   |Opt|
   |   |   |   |   |   |   |   |Out|
   +---+---+---+---+---+---+---+---+

      bit 7 is the Opt-Out flag.

      bits 0 - 6 are available for assignment.

   Assignment of additional NSEC3 Flags in this registry requires IETF
   Standards Action [RFC2434].

   This document creates a new IANA registry for NSEC3PARAM flags.  This
   registry is named "DNSSEC NSEC3PARAM Flags".  The initial contents of
   this registry are:



Laurie, et al.              Standards Track                    [Page 29]

RFC 5155                         NSEC3                        March 2008


     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   | 0 |
   +---+---+---+---+---+---+---+---+

      bit 7 is reserved and must be 0.

      bits 0 - 6 are available for assignment.

   Assignment of additional NSEC3PARAM Flags in this registry requires
   IETF Standards Action [RFC2434].

   Finally, this document creates a new IANA registry for NSEC3 hash
   algorithms.  This registry is named "DNSSEC NSEC3 Hash Algorithms".
   The initial contents of this registry are:

      0 is Reserved.

      1 is SHA-1.

      2-255 Available for assignment.

   Assignment of additional NSEC3 hash algorithms in this registry
   requires IETF Standards Action [RFC2434].

12.  Security Considerations

12.1.  Hashing Considerations

12.1.1.  Dictionary Attacks

   The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
   attacker retrieves all the NSEC3 RRs, then calculates the hashes of
   all likely domain names, comparing against the hashes found in the
   NSEC3 RRs, and thus enumerating the zone).  These are substantially
   more expensive than enumerating the original NSEC RRs would have
   been, and in any case, such an attack could also be used directly
   against the name server itself by performing queries for all likely
   names, though this would obviously be more detectable.  The expense
   of this off-line attack can be chosen by setting the number of
   iterations in the NSEC3 RR.

   Zones are also susceptible to a pre-calculated dictionary attack --
   that is, a list of hashes for all likely names is computed once, then
   NSEC3 RR is scanned periodically and compared against the precomputed
   hashes.  This attack is prevented by changing the salt on a regular
   basis.




Laurie, et al.              Standards Track                    [Page 30]

RFC 5155                         NSEC3                        March 2008


   The salt SHOULD be at least 64 bits long and unpredictable, so that
   an attacker cannot anticipate the value of the salt and compute the
   next set of dictionaries before the zone is published.

12.1.2.  Collisions

   Hash collisions between QNAME and the owner name of an NSEC3 RR may
   occur.  When they do, it will be impossible to prove the non-
   existence of the colliding QNAME.  However, with SHA-1, this is
   highly unlikely (on the order of 1 in 2^160).  Note that DNSSEC
   already relies on the presumption that a cryptographic hash function
   is second pre-image resistant, since these hash functions are used
   for generating and validating signatures and DS RRs.

12.1.3.  Transitioning to a New Hash Algorithm

   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
   parameter, this document does not define a particular mechanism for
   safely transitioning from one NSEC3 hash algorithm to another.  When
   specifying a new hash algorithm for use with NSEC3, a transition
   mechanism MUST also be defined.  It is possible that the only
   practical and palatable transition mechanisms may require an
   intermediate transition to an insecure state, or to a state that uses
   NSEC records instead of NSEC3.

12.1.4.  Using High Iteration Values

   Since validators should treat responses containing NSEC3 RRs with
   high iteration values as insecure, presence of just one signed NSEC3
   RR with a high iteration value in a zone provides attackers with a
   possible downgrade attack.

   The attack is simply to remove any existing NSEC3 RRs from a
   response, and replace or add a single (or multiple) NSEC3 RR that
   uses a high iterations value to the response.  Validators will then
   be forced to treat the response as insecure.  This attack would be
   effective only when all of following conditions are met:

   o  There is at least one signed NSEC3 RR that uses a high iterations
      value present in the zone.

   o  The attacker has access to one or more of these NSEC3 RRs.  This
      is trivially true when the NSEC3 RRs with high iteration values
      are being returned in typical responses, but may also be true if
      the attacker can access the zone via AXFR or IXFR queries, or any
      other methodology.





Laurie, et al.              Standards Track                    [Page 31]

RFC 5155                         NSEC3                        March 2008


   Using a high number of iterations also introduces an additional
   denial-of-service opportunity against servers, since servers must
   calculate several hashes per negative or wildcard response.

12.2.  Opt-Out Considerations

   The Opt-Out Flag (O) allows for unsigned names, in the form of
   delegations to unsigned zones, to exist within an otherwise signed
   zone.  All unsigned names are, by definition, insecure, and their
   validity or existence cannot be cryptographically proven.

   In general:

   o  Resource records with unsigned names (whether existing or not)
      suffer from the same vulnerabilities as RRs in an unsigned zone.
      These vulnerabilities are described in more detail in [RFC3833]
      (note in particular Section 2.3, "Name Chaining" and Section 2.6,
      "Authenticated Denial of Domain Names").

   o  Resource records with signed names have the same security whether
      or not Opt-Out is used.

   Note that with or without Opt-Out, an insecure delegation may be
   undetectably altered by an attacker.  Because of this, the primary
   difference in security when using Opt-Out is the loss of the ability
   to prove the existence or nonexistence of an insecure delegation
   within the span of an Opt-Out NSEC3 RR.

   In particular, this means that a malicious entity may be able to
   insert or delete RRs with unsigned names.  These RRs are normally NS
   RRs, but this also includes signed wildcard expansions (while the
   wildcard RR itself is signed, its expanded name is an unsigned name).

   Note that being able to add a delegation is functionally equivalent
   to being able to add any RR type: an attacker merely has to forge a
   delegation to name server under his/her control and place whatever
   RRs needed at the subzone apex.

   While in particular cases, this issue may not present a significant
   security problem, in general it should not be lightly dismissed.
   Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
   In particular, zone signing tools SHOULD NOT default to using Opt-
   Out, and MAY choose to not support Opt-Out at all.








Laurie, et al.              Standards Track                    [Page 32]

RFC 5155                         NSEC3                        March 2008


12.3.  Other Considerations

   Walking the NSEC3 RRs will reveal the total number of RRs in the zone
   (plus empty non-terminals), and also what types there are.  This
   could be mitigated by adding dummy entries, but certainly an upper
   limit can always be found.

13.  References

13.1.  Normative References

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

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

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2136]         Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
                     "Dynamic Updates in the Domain Name System (DNS
                     UPDATE)", RFC 2136, April 1997.

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

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

   [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
                     Writing an IANA Considerations Section in RFCs",
                     BCP 26, RFC 2434, October 1998.

   [RFC2929]         Eastlake, D., Brunner-Williams, E., and B. Manning,
                     "Domain Name System (DNS) IANA Considerations",
                     BCP 42, RFC 2929, September 2000.

   [RFC3597]         Gustafsson, A., "Handling of Unknown DNS Resource
                     Record (RR) Types", RFC 3597, September 2003.

   [RFC4033]         Arends, R., Austein, R., Larson, M., Massey, D.,
                     and S. Rose, "DNS Security Introduction and
                     Requirements", RFC 4033, March 2005.

   [RFC4034]         Arends, R., Austein, R., Larson, M., Massey, D.,
                     and S. Rose, "Resource Records for the DNS Security
                     Extensions", RFC 4034, March 2005.



Laurie, et al.              Standards Track                    [Page 33]

RFC 5155                         NSEC3                        March 2008


   [RFC4035]         Arends, R., Austein, R., Larson, M., Massey, D.,
                     and S. Rose, "Protocol Modifications for the DNS
                     Security Extensions", RFC 4035, March 2005.

   [RFC4648]         Josefsson, S., "The Base16, Base32, and Base64 Data
                     Encodings", RFC 4648, October 2006.

13.2.  Informative References

   [DNSEXT-NO]       Josefsson, S., "Authenticating Denial of Existence
                     in DNS with Minimum Disclosure", Work in Progress,
                     July 2000.

   [DNSEXT-NSEC2v2]  Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
                     Work in Progress, December 2004.

   [RFC2672]         Crawford, M., "Non-Terminal DNS Name Redirection",
                     RFC 2672, August 1999.

   [RFC2898]         Kaliski, B., "PKCS #5: Password-Based Cryptography
                     Specification Version 2.0", RFC 2898,
                     September 2000.

   [RFC3833]         Atkins, D. and R. Austein, "Threat Analysis of the
                     Domain Name System (DNS)", RFC 3833, August 2004.

   [RFC4592]         Lewis, E., "The Role of Wildcards in the Domain
                     Name System", RFC 4592, July 2006.

   [RFC4956]         Arends, R., Kosters, M., and D. Blacka, "DNS
                     Security (DNSSEC) Opt-In", RFC 4956, July 2007.




















Laurie, et al.              Standards Track                    [Page 34]

RFC 5155                         NSEC3                        March 2008


Appendix A.  Example Zone

   This is a zone showing its NSEC3 RRs.  They can also be used as test
   vectors for the hash algorithm.

   The overall TTL and class are specified in the SOA RR, and are
   subsequently omitted for clarity.

   The zone is preceded by a list that contains the hashes of the
   original ownernames.

   ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
   ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
   ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
   ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
   ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r
   ; H(w.example)     = k8udemvp1j2f7eg6jebps17vp3n8i58h
   ; H(*.w.example)   = r53bq7cc2uvmubfu5ocmm6pers9tk9en
   ; H(x.w.example)   = b4um86eghhds6nea196smvmlo4ors995
   ; H(y.w.example)   = ji6neoaepv8b5o6k4ev33abha8ht9fgc
   ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
   ; H(xx.example)    = t644ebqk9bibcna874givr6joj62mlhv
   ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
   ;                  = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
   example. 3600  IN SOA  ns1.example. bugs.x.w.example. 1 3600 300 (
                          3600000 3600 )
                  RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
                          40430 example.
                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
                          VI2LmKusbZsT0Q== )
                  NS      ns1.example.
                  NS      ns2.example.
                  RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
                          40430 example.
                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
                          CnMXjtz6SyObxA== )
                  MX      1 xx.example.
                  RRSIG   MX 7 1 3600 20150420235959 20051021000000 (
                          40430 example.
                          GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
                          9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
                          n9Mto/Kx+wBo+w== )
                  DNSKEY  256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
                          sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
                          TY4hHn9npWFRw5BYubE= )




Laurie, et al.              Standards Track                    [Page 35]

RFC 5155                         NSEC3                        March 2008


                  DNSKEY  257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
                          j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
                          AbsUdblMFin8CVF3n4s= )
                  RRSIG   DNSKEY 7 1 3600 20150420235959 (
                          20051021000000 12708 example.
                          AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
                          uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
                          MGQZf3bH+QsCtg== )
                  NSEC3PARAM 1 0 12 aabbccdd
                  RRSIG   NSEC3PARAM 7 1 3600 20150420235959 (
                          20051021000000 40430 example.
                          C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
                          rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
                          TLQsjlkynhG6Cg== )
   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
                          SOA NSEC3PARAM RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
                          BOCXJZMnpuwhpA== )
   2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
                          K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
                          k8p6xHMPZumXlw== )
                  NSEC3   1 1 12 aabbccdd (
                          2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
                          4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
                          NI6mRk/r1dOSUw== )
   2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
                          35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
                          VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
                          TuktZ+sdsZPY1w== )
   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )







Laurie, et al.              Standards Track                    [Page 36]

RFC 5155                         NSEC3                        March 2008


                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
                          XtAIR3chwgW+SA== )
   a.example.     NS      ns1.a.example.
                  NS      ns2.a.example.
                  DS      58470 5 1 (
                          3079F1593EBAD6DC121E202A8B766A6A4837206C )
                  RRSIG   DS 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
                          M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
                          o722vZ4UZ2dIdA== )
   ns1.a.example. A       192.0.2.5
   ns2.a.example. A       192.0.2.6
   ai.example.    A       192.0.2.9
                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
                          rznEn8sQ64UdqA== )
                  HINFO   "KLH-10" "ITS"
                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
                          enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
                          v0wLHpEZG7Xj2w== )
                  AAAA    2001:db8:0:0:0:0:f00:baa9
                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
                          cHueLuXkMjBArQ== )
   b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
                          gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
                          5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
                          pOv0TSTyiTxIZg== )
   c.example.     NS      ns1.c.example.
                  NS      ns2.c.example.
   ns1.c.example. A       192.0.2.7
   ns2.c.example. A       192.0.2.8
   gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
                          ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
                          RRSIG )



Laurie, et al.              Standards Track                    [Page 37]

RFC 5155                         NSEC3                        March 2008


                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
                          LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
                          Dy+rdGIeRSVNyw== )
   ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
                          k8udemvp1j2f7eg6jebps17vp3n8i58h )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
                          2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
                          MpzVSKfTwx4uYA== )
   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
                          Otx7w9WfcIg62A== )
   kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
                          q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
                          6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
                          QJazmASFKGxGXg== )
   ns1.example.   A       192.0.2.1
                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
                          kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
                          4FRvZR9SCFHF5Q== )
   ns2.example.   A       192.0.2.2
                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
                          zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
                          4IHfeX6n8vfoGA== )
   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
                          NlkxWcLsIlMmUg== )






Laurie, et al.              Standards Track                    [Page 38]

RFC 5155                         NSEC3                        March 2008


   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
                          HF1FWKW7RIJdtQ== )
   t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
                          0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
                          RRSIG )
                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
                          fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
                          X1xPl1ATNa+8Dw== )
   *.w.example.   MX      1 ai.example.
                  RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
                          ivEBP6+4KS3ldA== )
   x.w.example.   MX      1 xx.example.
                  RRSIG   MX 7 3 3600 20150420235959 20051021000000 (
                          40430 example.
                          IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
                          QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
                          7WCtwwekLKRAwQ== )
   x.y.w.example. MX      1 xx.example.
                  RRSIG   MX 7 4 3600 20150420235959 20051021000000 (
                          40430 example.
                          MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
                          nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
                          8/8Ccl2Zn2hbug== )
   xx.example.    A       192.0.2.10
                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
                          YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
                          pQvhq+Ac6+ZiFg== )
                  HINFO   "KLH-10" "TOPS-20"
                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
                          FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
                          6Jfqj/8NzWjvKg== )
                  AAAA    2001:db8:0:0:0:0:f00:baaa





Laurie, et al.              Standards Track                    [Page 39]

RFC 5155                         NSEC3                        March 2008


                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
                          uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
                          NzYfMItpILl/Xw== )

Appendix B.  Example Responses

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

B.1.  Name Error

   An authoritative name error.  The NSEC3 RRs prove that the name does
   not exist and that there is no wildcard RR that should have been
   expanded.

;; Header: QR AA DO RCODE=3
;;
;; Question
a.c.x.w.example.         IN A

;; Answer
;; (empty)

;; Authority

example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
                       3600000 3600 )
example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
                       40430 example.
                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
                       VI2LmKusbZsT0Q== )

;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh

0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
                       SOA NSEC3PARAM RRSIG )
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
                       20150420235959 20051021000000 40430 example.
                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
                       BOCXJZMnpuwhpA== )





Laurie, et al.              Standards Track                    [Page 40]

RFC 5155                         NSEC3                        March 2008


;; NSEC3 RR that matches the closest encloser (x.w.example)
;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995

b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
                       gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
                       20150420235959 20051021000000 40430 example.
                       ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
                       5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
                       pOv0TSTyiTxIZg== )

;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m

35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
                       b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
                       20150420235959 20051021000000 40430 example.
                       g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
                       Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
                       XtAIR3chwgW+SA== )

;; Additional
;; (empty)

   The query returned three NSEC3 RRs that prove that the requested data
   does not exist and that no wildcard expansion applies.  The negative
   response is authenticated by verifying the NSEC3 RRs.  The
   corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
   "example" DNSKEY of algorithm 7 and with key tag 40430.  The resolver
   needs the corresponding DNSKEY RR in order to authenticate this
   answer.

   One of the owner names of the NSEC3 RRs matches the closest encloser.
   One of the NSEC3 RRs prove that there exists no longer name.  One of
   the NSEC3 RRs prove that there exists no wildcard RRSets that should
   have been expanded.  The closest encloser can be found by applying
   the algorithm in Section 8.3.

   In the above example, the name 'x.w.example' hashes to
   'b4um86eghhds6nea196smvmlo4ors995'.  This indicates that this might
   be the closest encloser.  To prove that 'c.x.w.example' and
   '*.x.w.example' do not exist, these names are hashed to,
   respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
   '92pqneegtaue7pjatc3l3qnk738c6v5m'.  The first and last NSEC3 RRs
   prove that these hashed owner names do not exist.





Laurie, et al.              Standards Track                    [Page 41]

RFC 5155                         NSEC3                        March 2008


B.2.  No Data Error

   A "no data" response.  The NSEC3 RR proves that the name exists and
   that the requested RR type does not.

;; Header: QR AA DO RCODE=0
;;
;; Question
ns1.example.        IN MX

;; Answer
;; (empty)

;; Authority
example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
                       3600000 3600 )
example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
                       40430 example.
                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
                       VI2LmKusbZsT0Q== )

;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.

2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
                       2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
                       20150420235959 20051021000000 40430 example.
                       OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
                       4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
                       NI6mRk/r1dOSUw== )
;; Additional
;; (empty)

   The query returned an NSEC3 RR that proves that the requested name
   exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
   but the requested RR type does not exist (type MX is absent in the
   type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
   also absent in the type code list of the NSEC3 RR).












Laurie, et al.              Standards Track                    [Page 42]

RFC 5155                         NSEC3                        March 2008


B.2.1.  No Data Error, Empty Non-Terminal

   A "no data" response because of an empty non-terminal.  The NSEC3 RR
   proves that the name exists and that the requested RR type does not.

 ;; Header: QR AA DO RCODE=0
 ;;
 ;; Question
 y.w.example.        IN A

 ;; Answer
 ;; (empty)

 ;; Authority
 example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
                        3600000 3600 )
 example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
                        40430 example.
                        Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
                        q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
                        VI2LmKusbZsT0Q== )

 ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.

 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
                        k8udemvp1j2f7eg6jebps17vp3n8i58h )
 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
                        20150420235959 20051021000000 40430 example.
                        gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
                        2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
                        MpzVSKfTwx4uYA== )

 ;; Additional
 ;; (empty)

   The query returned an NSEC3 RR that proves that the requested name
   exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
   but the requested RR type does not exist (Type A is absent in the
   Type Bit Maps field of the NSEC3 RR).  Note that, unlike an empty
   non-terminal proof using NSECs, this is identical to a No Data Error.
   This example is solely mentioned to be complete.










Laurie, et al.              Standards Track                    [Page 43]

RFC 5155                         NSEC3                        March 2008


B.3.  Referral to an Opt-Out Unsigned Zone

   The NSEC3 RRs prove that nothing for this delegation was signed.
   There is no proof that the unsigned delegation exists.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.c.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   c.example.     NS      ns1.c.example.
                  NS      ns2.c.example.

   ;; NSEC3 RR that covers the "next closer" name (c.example)
   ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck

   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
   35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
                          20150420235959 20051021000000 40430 example.
                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
                          XtAIR3chwgW+SA== )

   ;; NSEC3 RR that matches the closest encloser (example)
   ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom

   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
                          SOA NSEC3PARAM RRSIG )
   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
                          20150420235959 20051021000000 40430 example.
                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
                          BOCXJZMnpuwhpA== )

   ;; Additional
   ns1.c.example. A       192.0.2.7
   ns2.c.example. A       192.0.2.8

   The query returned a referral to the unsigned "c.example." zone.  The
   response contains the closest provable encloser of "c.example" to be
   "example", since the hash of "c.example"




Laurie, et al.              Standards Track                    [Page 44]

RFC 5155                         NSEC3                        March 2008


   ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
   and its Opt-Out bit is set.

B.4.  Wildcard Expansion

   A query that was answered with a response containing a wildcard
   expansion.  The label count in the RRSIG RRSet in the answer section
   indicates that a wildcard RRSet was expanded to produce this
   response, and the NSEC3 RR proves that no "next closer" name exists
   in the zone.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   a.z.w.example. IN MX

   ;; Answer
   a.z.w.example. MX      1 ai.example.
   a.z.w.example. RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
                          ivEBP6+4KS3ldA== )

   ;; Authority
   example.       NS      ns1.example.
   example.       NS      ns2.example.
   example.       RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
                          40430 example.
                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
                          CnMXjtz6SyObxA== )

   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03

   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
                          20150420235959 20051021000000 40430 example.
                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
                          NlkxWcLsIlMmUg== )








Laurie, et al.              Standards Track                    [Page 45]

RFC 5155                         NSEC3                        March 2008


   ;; Additional
   ai.example.    A       192.0.2.9
   ai.example.    RRSIG   A 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
                          rznEn8sQ64UdqA== )
   ai.example.    AAAA    2001:db8:0:0:0:0:f00:baa9
   ai.example.    RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
                          40430 example.
                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
                          cHueLuXkMjBArQ== )

   The query returned an answer that was produced as a result of a
   wildcard expansion.  The answer section contains a wildcard RRSet
   expanded as it would be in a traditional DNS response.  The RRSIG
   Labels field value of 2 indicates that the answer is the result of a
   wildcard expansion, as the "a.z.w.example" name contains 4 labels.
   This also shows that "w.example" exists, so there is no need for an
   NSEC3 RR that matches the closest encloser.

   The NSEC3 RR proves that no closer match could have been used to
   answer this query.

B.5.  Wildcard No Data Error

   A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
   prove that the matching wildcard name does not have any RRs of the
   requested type and that no closer match exists in the zone.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   a.z.w.example.      IN AAAA

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
                          3600000 3600 )
   example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
                          40430 example.
                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
                          VI2LmKusbZsT0Q== )




Laurie, et al.              Standards Track                    [Page 46]

RFC 5155                         NSEC3                        March 2008


   ;; NSEC3 RR that matches the closest encloser (w.example)
   ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h

   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
                          20150420235959 20051021000000 40430 example.
                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
                          Otx7w9WfcIg62A== )

   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03

   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
                          20150420235959 20051021000000 40430 example.
                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
                          NlkxWcLsIlMmUg== )

   ;; NSEC3 RR that matches a wildcard at the closest encloser.
   ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en

   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
                          20150420235959 20051021000000 40430 example.
                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
                          HF1FWKW7RIJdtQ== )

   ;; Additional
   ;; (empty)

   The query returned the NSEC3 RRs that prove that the requested data
   does not exist and no wildcard RR applies.













Laurie, et al.              Standards Track                    [Page 47]

RFC 5155                         NSEC3                        March 2008


B.6.  DS Child Zone No Data Error

   A "no data" response for a QTYPE=DS query that was mistakenly sent to
   a name server for the child zone.

;; Header: QR AA DO RCODE=0
;;
;; Question
example.            IN DS

;; Answer
;; (empty)

;; Authority
example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
                       3600000 3600 )
example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
                       40430 example.
                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
                       VI2LmKusbZsT0Q== )

;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.

0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
                       SOA NSEC3PARAM RRSIG )
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
                       20150420235959 20051021000000 40430 example.
                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
                       BOCXJZMnpuwhpA== )

;; Additional
;; (empty)

   The query returned an NSEC3 RR showing that the requested was
   answered by the server authoritative for the zone "example".  The
   NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
   RR is from the apex of the child, not from the zone cut of the
   parent.  Queries for the "example" DS RRSet should be sent to the
   parent servers (which are in this case the root servers).

Appendix C.  Special Considerations

   The following paragraphs clarify specific behavior and explain
   special considerations for implementations.




Laurie, et al.              Standards Track                    [Page 48]

RFC 5155                         NSEC3                        March 2008


C.1.  Salting

   Augmenting original owner names with salt before hashing increases
   the cost of a dictionary of pre-generated hash-values.  For every bit
   of salt, the cost of a precomputed dictionary doubles (because there
   must be an entry for each word combined with each possible salt
   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
   salt, multiplying the cost by 2^2040.  This means that an attacker
   must, in practice, recompute the dictionary each time the salt is
   changed.

   Including a salt, regardless of size, does not affect the cost of
   constructing NSEC3 RRs.  It does increase the size of the NSEC3 RR.

   There MUST be at least one complete set of NSEC3 RRs for the zone
   using the same salt value.

   The salt SHOULD be changed periodically to prevent pre-computation
   using a single salt.  It is RECOMMENDED that the salt be changed for
   every re-signing.

   Note that this could cause a resolver to see RRs with different salt
   values for the same zone.  This is harmless, since each RR stands
   alone (that is, it denies the set of owner names whose hashes, using
   the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
   RR) -- it is only the server that needs a complete set of NSEC3 RRs
   with the same salt in order to be able to answer every possible
   query.

   There is no prohibition with having NSEC3 RRs with different salts
   within the same zone.  However, in order for authoritative servers to
   be able to consistently find covering NSEC3 RRs, the authoritative
   server MUST choose a single set of parameters (algorithm, salt, and
   iterations) to use when selecting NSEC3 RRs.

C.2.  Hash Collision

   Hash collisions occur when different messages have the same hash
   value.  The expected number of domain names needed to give a 1 in 2
   chance of a single collision is about 2^(n/2) for a hash of length n
   bits (i.e., 2^80 for SHA-1).  Though this probability is extremely
   low, the following paragraphs deal with avoiding collisions and
   assessing possible damage in the event of an attack using hash
   collisions.







Laurie, et al.              Standards Track                    [Page 49]

RFC 5155                         NSEC3                        March 2008


C.2.1.  Avoiding Hash Collisions During Generation

   During generation of NSEC3 RRs, hash values are supposedly unique.
   In the (academic) case of a collision occurring, an alternative salt
   MUST be chosen and all hash values MUST be regenerated.

C.2.2.  Second Preimage Requirement Analysis

   A cryptographic hash function has a second-preimage resistance
   property.  The second-preimage resistance property means that it is
   computationally infeasible to find another message with the same hash
   value as a given message, i.e., given preimage X, to find a second
   preimage X' != X such that hash(X) = hash(X').  The work factor for
   finding a second preimage is of the order of 2^160 for SHA-1.  To
   mount an attack using an existing NSEC3 RR, an adversary needs to
   find a second preimage.

   Assuming an adversary is capable of mounting such an extreme attack,
   the actual damage is that a response message can be generated that
   claims that a certain QNAME (i.e., the second pre-image) does exist,
   while in reality QNAME does not exist (a false positive), which will
   either cause a security-aware resolver to re-query for the non-
   existent name, or to fail the initial query.  Note that the adversary
   can't mount this attack on an existing name, but only on a name that
   the adversary can't choose and that does not yet exist.


























Laurie, et al.              Standards Track                    [Page 50]

RFC 5155                         NSEC3                        March 2008


Authors' Addresses

   Ben Laurie
   Nominet
   17 Perryn Road
   London  W3 7LR
   England

   Phone: +44 20 8735 0686
   EMail: ben@links.org


   Geoffrey Sisson
   Nominet
   Minerva House
   Edmund Halley Road
   Oxford Science Park
   Oxford  OX4 4DQ
   UNITED KINGDOM

   Phone: +44 1865 332211
   EMail: geoff-s@panix.com


   Roy Arends
   Nominet
   Minerva House
   Edmund Halley Road
   Oxford Science Park
   Oxford  OX4 4DQ
   UNITED KINGDOM

   Phone: +44 1865 332211
   EMail: roy@nominet.org.uk


   David Blacka
   VeriSign, Inc.
   21355 Ridgetop Circle
   Dulles, VA  20166
   US

   Phone: +1 703 948 3200
   EMail: davidb@verisign.com







Laurie, et al.              Standards Track                    [Page 51]

RFC 5155                         NSEC3                        March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












Laurie, et al.              Standards Track                    [Page 52]