summaryrefslogtreecommitdiffstats
path: root/doc/rfc/rfc5155.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5155.txt')
-rw-r--r--doc/rfc/rfc5155.txt2915
1 files changed, 2915 insertions, 0 deletions
diff --git a/doc/rfc/rfc5155.txt b/doc/rfc/rfc5155.txt
new file mode 100644
index 0000000..d4b7297
--- /dev/null
+++ b/doc/rfc/rfc5155.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+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]
+
generated by cgit (git 2.34.1) at 2024-04-27 00:30:32 +0000