7Network Working Group B. Laurie
8Request for Comments: 5155 G. Sisson
9Category: Standards Track R. Arends
16 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
28 The Domain Name System Security (DNSSEC) Extensions introduced the
29 NSEC resource record (RR) for authenticated denial of existence.
30 This document introduces an alternative resource record, NSEC3, which
31 similarly provides authenticated denial of existence. However, it
32 also provides measures against zone enumeration and permits gradual
33 expansion of delegation-centric zones.
37 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
38 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
39 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
40 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
41 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
42 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 7
43 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8
44 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8
45 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8
46 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8
47 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 8
48 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 8
49 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9
50 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9
51 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9
52 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
53 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
54 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 11
58Laurie, et al. Standards Track [Page 1]
60RFC 5155 NSEC3 March 2008
63 4. The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
64 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
65 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
66 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 12
67 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13
68 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13
69 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
70 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
71 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 14
72 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 14
73 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
74 7. Authoritative Server Considerations . . . . . . . . . . . . . 16
75 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
76 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
77 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18
78 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 19
79 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19
80 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
81 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 19
82 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 20
83 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20
84 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20
85 7.2.9. Server Response to a Run-Time Collision . . . . . . . 21
86 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 21
87 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21
88 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
89 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 23
90 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 23
91 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 23
92 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
93 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24
94 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24
95 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24
96 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 25
97 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 25
98 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25
99 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 26
100 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 26
101 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 26
102 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
103 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26
104 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
105 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
106 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
107 10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
109 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
110 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
114Laurie, et al. Standards Track [Page 2]
116RFC 5155 NSEC3 March 2008
119 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
120 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
121 12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 31
122 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31
123 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
124 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
126 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
127 13.2. Informative References . . . . . . . . . . . . . . . . . . 34
128 Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 35
129 Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 40
130 B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
131 B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 42
132 B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 43
133 B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
134 B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
135 B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
136 B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 48
137 Appendix C. Special Considerations . . . . . . . . . . . . . . . 48
138 C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 49
139 C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
140 C.2.1. Avoiding Hash Collisions During Generation . . . . . . 50
141 C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 50
170Laurie, et al. Standards Track [Page 3]
172RFC 5155 NSEC3 March 2008
179 The DNS Security Extensions included the NSEC RR to provide
180 authenticated denial of existence. Though the NSEC RR meets the
181 requirements for authenticated denial of existence, it introduces a
182 side-effect in that the contents of a zone can be enumerated. This
183 property introduces undesired policy issues.
185 The enumeration is enabled by the set of NSEC records that exists
186 inside a signed zone. An NSEC record lists two names that are
187 ordered canonically, in order to show that nothing exists between the
188 two names. The complete set of NSEC records lists all the names in a
189 zone. It is trivial to enumerate the content of a zone by querying
190 for names that do not exist.
192 An enumerated zone can be used, for example, as a source of probable
193 e-mail addresses for spam, or as a key for multiple WHOIS queries to
194 reveal registrant data that many registries may have legal
195 obligations to protect. Many registries therefore prohibit the
196 copying of their zone data; however, the use of NSEC RRs renders
197 these policies unenforceable.
199 A second problem is that the cost to cryptographically secure
200 delegations to unsigned zones is high, relative to the perceived
201 security benefit, in two cases: large, delegation-centric zones, and
202 zones where insecure delegations will be updated rapidly. In these
203 cases, the costs of maintaining the NSEC RR chain may be extremely
204 high and use of the "Opt-Out" convention may be more appropriate (for
205 these unsecured zones).
207 This document presents the NSEC3 Resource Record which can be used as
208 an alternative to NSEC to mitigate these issues.
210 Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
211 and [DNSEXT-NSEC2v2].
215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
217 document are to be interpreted as described in [RFC2119].
226Laurie, et al. Standards Track [Page 4]
228RFC 5155 NSEC3 March 2008
233 The reader is assumed to be familiar with the basic DNS and DNSSEC
234 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
235 [RFC4035], and subsequent RFCs that update them: [RFC2136],
236 [RFC2181], and [RFC2308].
238 The following terminology is used throughout this document:
240 Zone enumeration: the practice of discovering the full content of a
241 zone via successive queries. Zone enumeration was non-trivial
242 prior to the introduction of DNSSEC.
244 Original owner name: the owner name corresponding to a hashed owner
247 Hashed owner name: the owner name created after applying the hash
248 function to an owner name.
250 Hash order: the order in which hashed owner names are arranged
251 according to their numerical value, treating the leftmost (lowest
252 numbered) octet as the most significant octet. Note that this
253 order is the same as the canonical DNS name order specified in
254 [RFC4034], when the hashed owner names are in base32, encoded with
255 an Extended Hex Alphabet [RFC4648].
257 Empty non-terminal: a domain name that owns no resource records, but
258 has one or more subdomains that do.
260 Delegation: an NS RRSet with a name different from the current zone
261 apex (non-zone-apex), signifying a delegation to a child zone.
263 Secure delegation: a name containing a delegation (NS RRSet) and a
264 signed DS RRSet, signifying a delegation to a signed child zone.
266 Insecure delegation: a name containing a delegation (NS RRSet), but
267 lacking a DS RRSet, signifying a delegation to an unsigned child
270 Opt-Out NSEC3 resource record: an NSEC3 resource record that has the
271 Opt-Out flag set to 1.
273 Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR.
275 Closest encloser: the longest existing ancestor of a name. See also
276 Section 3.3.1 of [RFC4592].
282Laurie, et al. Standards Track [Page 5]
284RFC 5155 NSEC3 March 2008
287 Closest provable encloser: the longest ancestor of a name that can
288 be proven to exist. Note that this is only different from the
289 closest encloser in an Opt-Out zone.
291 Next closer name: the name one label longer than the closest
292 provable encloser of a name.
294 Base32: the "Base 32 Encoding with Extended Hex Alphabet" as
295 specified in [RFC4648]. Note that trailing padding characters
296 ("=") are not used in the NSEC3 specification.
298 To cover: An NSEC3 RR is said to "cover" a name if the hash of the
299 name or "next closer" name falls between the owner name and the
300 next hashed owner name of the NSEC3. In other words, if it proves
301 the nonexistence of the name, either directly or by proving the
302 nonexistence of an ancestor of the name.
304 To match: An NSEC3 RR is said to "match" a name if the owner name of
305 the NSEC3 RR is the same as the hashed owner name of that name.
3072. Backwards Compatibility
309 This specification describes a protocol change that is not generally
310 backwards compatible with [RFC4033], [RFC4034], and [RFC4035]. In
311 particular, security-aware resolvers that are unaware of this
312 specification (NSEC3-unaware resolvers) may fail to validate the
313 responses introduced by this document.
315 In order to aid deployment, this specification uses a signaling
316 technique to prevent NSEC3-unaware resolvers from attempting to
317 validate responses from NSEC3-signed zones.
319 This specification allocates two new DNSKEY algorithm identifiers for
320 this purpose. Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
321 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
322 RSASHA1. These are not new algorithms, they are additional
323 identifiers for the existing algorithms.
325 Zones signed according to this specification MUST only use these
326 algorithm identifiers for their DNSKEY RRs. Because these new
327 identifiers will be unknown algorithms to existing, NSEC3-unaware
328 resolvers, those resolvers will then treat responses from the NSEC3
329 signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
331 These algorithm identifiers are used with the NSEC3 hash algorithm
332 SHA1. Using other NSEC3 hash algorithms requires allocation of a new
333 alias (see Section 12.1.3).
338Laurie, et al. Standards Track [Page 6]
340RFC 5155 NSEC3 March 2008
343 Security aware resolvers that are aware of this specification MUST
344 recognize the new algorithm identifiers and treat them as equivalent
345 to the algorithms that they alias.
347 A methodology for transitioning from a DNSSEC signed zone to a zone
348 signed using NSEC3 is discussed in Section 10.4.
3503. The NSEC3 Resource Record
352 The NSEC3 Resource Record (RR) provides authenticated denial of
353 existence for DNS Resource Record Sets.
355 The NSEC3 RR lists RR types present at the original owner name of the
356 NSEC3 RR. It includes the next hashed owner name in the hash order
357 of the zone. The complete set of NSEC3 RRs in a zone indicates which
358 RRSets exist for the original owner name of the RR and form a chain
359 of hashed owner names in the zone. This information is used to
360 provide authenticated denial of existence for DNS data. To provide
361 protection against zone enumeration, the owner names used in the
362 NSEC3 RR are cryptographic hashes of the original owner name
363 prepended as a single label to the name of the zone. The NSEC3 RR
364 indicates which hash function is used to construct the hash, which
365 salt is used, and how many iterations of the hash function are
366 performed over the original owner name. The hashing technique is
367 described fully in Section 5.
369 Hashed owner names of unsigned delegations may be excluded from the
370 chain. An NSEC3 RR whose span covers the hash of an owner name or
371 "next closer" name of an unsigned delegation is referred to as an
372 Opt-Out NSEC3 RR and is indicated by the presence of a flag.
374 The owner name for the NSEC3 RR is the base32 encoding of the hashed
375 owner name prepended as a single label to the name of the zone.
377 The type value for the NSEC3 RR is 50.
379 The NSEC3 RR RDATA format is class independent and is described
382 The class MUST be the same as the class of the original owner name.
384 The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
385 field. This is in the spirit of negative caching [RFC2308].
394Laurie, et al. Standards Track [Page 7]
396RFC 5155 NSEC3 March 2008
403 The Hash Algorithm field identifies the cryptographic hash algorithm
404 used to construct the hash-value.
406 The values for this field are defined in the NSEC3 hash algorithm
407 registry defined in Section 11.
411 The Flags field contains 8 one-bit flags that can be used to indicate
412 different processing. All undefined flags must be zero. The only
413 flag defined by this specification is the Opt-Out flag.
417 If the Opt-Out flag is set, the NSEC3 record covers zero or more
418 unsigned delegations.
420 If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
423 The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
424 delegations. It is the least significant bit in the Flags field.
425 See Section 6 for details about the use of this flag.
429 The Iterations field defines the number of additional times the hash
430 function has been performed. More iterations result in greater
431 resiliency of the hash value against dictionary attacks, but at a
432 higher computational cost for both the server and resolver. See
433 Section 5 for details of the use of this field, and Section 10.3 for
434 limitations on the value.
438 The Salt Length field defines the length of the Salt field in octets,
439 ranging in value from 0 to 255.
443 The Salt field is appended to the original owner name before hashing
444 in order to defend against pre-calculated dictionary attacks. See
445 Section 5 for details on how the salt is used.
450Laurie, et al. Standards Track [Page 8]
452RFC 5155 NSEC3 March 2008
457 The Hash Length field defines the length of the Next Hashed Owner
458 Name field, ranging in value from 1 to 255 octets.
4603.1.7. Next Hashed Owner Name
462 The Next Hashed Owner Name field contains the next hashed owner name
463 in hash order. This value is in binary format. Given the ordered
464 set of all hashed owner names, the Next Hashed Owner Name field
465 contains the hash of an owner name that immediately follows the owner
466 name of the given NSEC3 RR. The value of the Next Hashed Owner Name
467 field in the last NSEC3 RR in the zone is the same as the hashed
468 owner name of the first NSEC3 RR in the zone in hash order. Note
469 that, unlike the owner name of the NSEC3 RR, the value of this field
470 does not contain the appended zone name.
474 The Type Bit Maps field identifies the RRSet types that exist at the
475 original owner name of the NSEC3 RR.
4773.2. NSEC3 RDATA Wire Format
479 The RDATA of the NSEC3 RR is as shown below:
481 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
482 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
483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
484 | Hash Alg. | Flags | Iterations |
485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
486 | Salt Length | Salt /
487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
488 | Hash Length | Next Hashed Owner Name /
489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
493 Hash Algorithm is a single octet.
495 Flags field is a single octet, the Opt-Out flag is the least
496 significant bit, as shown below:
506Laurie, et al. Standards Track [Page 9]
508RFC 5155 NSEC3 March 2008
511 Iterations is represented as a 16-bit unsigned integer, with the most
512 significant bit first.
514 Salt Length is represented as an unsigned octet. Salt Length
515 represents the length of the Salt field in octets. If the value is
516 zero, the following Salt field is omitted.
518 Salt, if present, is encoded as a sequence of binary octets. The
519 length of this field is determined by the preceding Salt Length
522 Hash Length is represented as an unsigned octet. Hash Length
523 represents the length of the Next Hashed Owner Name field in octets.
525 The next hashed owner name is not base32 encoded, unlike the owner
526 name of the NSEC3 RR. It is the unmodified binary hash value. It
527 does not include the name of the containing zone. The length of this
528 field is determined by the preceding Hash Length field.
5303.2.1. Type Bit Maps Encoding
532 The encoding of the Type Bit Maps field is the same as that used by
533 the NSEC RR, described in [RFC4034]. It is explained and clarified
536 The RR type space is split into 256 window blocks, each representing
537 the low-order 8 bits of the 16-bit RR type space. Each block that
538 has at least one active RR type is encoded using a single octet
539 window number (from 0 to 255), a single octet bitmap length (from 1
540 to 32) indicating the number of octets used for the bitmap of the
541 window block, and up to 32 octets (256 bits) of bitmap.
543 Blocks are present in the NSEC3 RR RDATA in increasing numerical
546 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
548 where "|" denotes concatenation.
550 Each bitmap encodes the low-order 8 bits of RR types within the
551 window block, in network bit order. The first bit is bit 0. For
552 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
553 to RR type 2 (NS), and so forth. For window block 1, bit 1
554 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
555 1, it indicates that an RRSet of that type is present for the
556 original owner name of the NSEC3 RR. If a bit is set to 0, it
557 indicates that no RRSet of that type is present for the original
558 owner name of the NSEC3 RR.
562Laurie, et al. Standards Track [Page 10]
564RFC 5155 NSEC3 March 2008
567 Since bit 0 in window block 0 refers to the non-existing RR type 0,
568 it MUST be set to 0. After verification, the validator MUST ignore
569 the value of bit 0 in window block 0.
571 Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
572 [RFC2929] or within the range reserved for assignment only to QTYPEs
573 and Meta-TYPEs MUST be set to 0, since they do not appear in zone
574 data. If encountered, they must be ignored upon reading.
576 Blocks with no types present MUST NOT be included. Trailing zero
577 octets in the bitmap MUST be omitted. The length of the bitmap of
578 each block is determined by the type code with the largest numerical
579 value, within that block, among the set of RR types present at the
580 original owner name of the NSEC3 RR. Trailing octets not specified
581 MUST be interpreted as zero octets.
5833.3. Presentation Format
585 The presentation format of the RDATA portion is as follows:
587 o The Hash Algorithm field is represented as an unsigned decimal
588 integer. The value has a maximum of 255.
590 o The Flags field is represented as an unsigned decimal integer.
591 The value has a maximum of 255.
593 o The Iterations field is represented as an unsigned decimal
594 integer. The value is between 0 and 65535, inclusive.
596 o The Salt Length field is not represented.
598 o The Salt field is represented as a sequence of case-insensitive
599 hexadecimal digits. Whitespace is not allowed within the
600 sequence. The Salt field is represented as "-" (without the
601 quotes) when the Salt Length field has a value of 0.
603 o The Hash Length field is not represented.
605 o The Next Hashed Owner Name field is represented as an unpadded
606 sequence of case-insensitive base32 digits, without whitespace.
608 o The Type Bit Maps field is represented as a sequence of RR type
609 mnemonics. When the mnemonic is not known, the TYPE
610 representation as described in Section 5 of [RFC3597] MUST be
618Laurie, et al. Standards Track [Page 11]
620RFC 5155 NSEC3 March 2008
6234. The NSEC3PARAM Resource Record
625 The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
626 flags, iterations, and salt) needed by authoritative servers to
627 calculate hashed owner names. The presence of an NSEC3PARAM RR at a
628 zone apex indicates that the specified parameters may be used by
629 authoritative servers to choose an appropriate set of NSEC3 RRs for
630 negative responses. The NSEC3PARAM RR is not used by validators or
633 If an NSEC3PARAM RR is present at the apex of a zone with a Flags
634 field value of zero, then there MUST be an NSEC3 RR using the same
635 hash algorithm, iterations, and salt parameters present at every
636 hashed owner name in the zone. That is, the zone MUST contain a
637 complete set of NSEC3 RRs with the same hash algorithm, iterations,
640 The owner name for the NSEC3PARAM RR is the name of the zone apex.
642 The type value for the NSEC3PARAM RR is 51.
644 The NSEC3PARAM RR RDATA format is class independent and is described
647 The class MUST be the same as the NSEC3 RRs to which this RR refers.
651 The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
655 The Hash Algorithm field identifies the cryptographic hash algorithm
656 used to construct the hash-value.
658 The acceptable values are the same as the corresponding field in the
663 The Opt-Out flag is not used and is set to zero.
665 All other flags are reserved for future use, and must be zero.
667 NSEC3PARAM RRs with a Flags field value other than zero MUST be
674Laurie, et al. Standards Track [Page 12]
676RFC 5155 NSEC3 March 2008
681 The Iterations field defines the number of additional times the hash
684 Its acceptable values are the same as the corresponding field in the
689 The Salt Length field defines the length of the salt in octets,
690 ranging in value from 0 to 255.
694 The Salt field is appended to the original owner name before hashing.
6964.2. NSEC3PARAM RDATA Wire Format
698 The RDATA of the NSEC3PARAM RR is as shown below:
700 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
701 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
702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
703 | Hash Alg. | Flags | Iterations |
704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
705 | Salt Length | Salt /
706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
708 Hash Algorithm is a single octet.
710 Flags field is a single octet.
712 Iterations is represented as a 16-bit unsigned integer, with the most
713 significant bit first.
715 Salt Length is represented as an unsigned octet. Salt Length
716 represents the length of the following Salt field in octets. If the
717 value is zero, the Salt field is omitted.
719 Salt, if present, is encoded as a sequence of binary octets. The
720 length of this field is determined by the preceding Salt Length
730Laurie, et al. Standards Track [Page 13]
732RFC 5155 NSEC3 March 2008
7354.3. Presentation Format
737 The presentation format of the RDATA portion is as follows:
739 o The Hash Algorithm field is represented as an unsigned decimal
740 integer. The value has a maximum of 255.
742 o The Flags field is represented as an unsigned decimal integer.
743 The value has a maximum value of 255.
745 o The Iterations field is represented as an unsigned decimal
746 integer. The value is between 0 and 65535, inclusive.
748 o The Salt Length field is not represented.
750 o The Salt field is represented as a sequence of case-insensitive
751 hexadecimal digits. Whitespace is not allowed within the
752 sequence. This field is represented as "-" (without the quotes)
753 when the Salt Length field is zero.
7555. Calculation of the Hash
757 The hash calculation uses three of the NSEC3 RDATA fields: Hash
758 Algorithm, Salt, and Iterations.
760 Define H(x) to be the hash of x using the Hash Algorithm selected by
761 the NSEC3 RR, k to be the number of Iterations, and || to indicate
762 concatenation. Then define:
764 IH(salt, x, 0) = H(x || salt), and
766 IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
768 Then the calculated hash of an owner name is
770 IH(salt, owner name, iterations),
772 where the owner name is in the canonical form, defined as:
774 The wire format of the owner name where:
776 1. The owner name is fully expanded (no DNS name compression) and
779 2. All uppercase US-ASCII letters are replaced by the corresponding
780 lowercase US-ASCII letters;
786Laurie, et al. Standards Track [Page 14]
788RFC 5155 NSEC3 March 2008
791 3. If the owner name is a wildcard name, the owner name is in its
792 original unexpanded form, including the "*" label (no wildcard
795 This form is as defined in Section 6.2 of [RFC4034].
797 The method to calculate the Hash is based on [RFC2898].
801 In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
802 RRSets at delegation points are not signed and may be accompanied by
803 a DS RRSet. With the Opt-Out bit clear, the security status of the
804 child zone is determined by the presence or absence of this DS RRSet,
805 cryptographically proven by the signed NSEC3 RR at the hashed owner
806 name of the delegation. Setting the Opt-Out flag modifies this by
807 allowing insecure delegations to exist within the signed zone without
808 a corresponding NSEC3 RR at the hashed owner name of the delegation.
810 An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
811 owner name or "next closer" name of the delegation is between the
812 owner name of the NSEC3 RR and the next hashed owner name.
814 An Opt-Out NSEC3 RR does not assert the existence or non-existence of
815 the insecure delegations that it may cover. This allows for the
816 addition or removal of these delegations without recalculating or re-
817 signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do
818 assert the (non)existence of other, authoritative RRSets.
820 An Opt-Out NSEC3 RR MAY have the same original owner name as an
821 insecure delegation. In this case, the delegation is proven insecure
822 by the lack of a DS bit in the type map and the signed NSEC3 RR does
823 assert the existence of the delegation.
825 Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
826 non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT
827 be any hashed owner names of insecure delegations (nor any other RRs)
828 between it and the name indicated by the next hashed owner name in
829 the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner
830 names or hashed "next closer" names of insecure delegations.
832 The effects of the Opt-Out flag on signing, serving, and validating
833 responses are covered in following sections.
842Laurie, et al. Standards Track [Page 15]
844RFC 5155 NSEC3 March 2008
8477. Authoritative Server Considerations
851 Zones using NSEC3 must satisfy the following properties:
853 o Each owner name within the zone that owns authoritative RRSets
854 MUST have a corresponding NSEC3 RR. Owner names that correspond
855 to unsigned delegations MAY have a corresponding NSEC3 RR.
856 However, if there is not a corresponding NSEC3 RR, there MUST be
857 an Opt-Out NSEC3 RR that covers the "next closer" name to the
858 delegation. Other non-authoritative RRs are not represented by
861 o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
862 the empty non-terminal is only derived from an insecure delegation
863 covered by an Opt-Out NSEC3 RR.
865 o The TTL value for any NSEC3 RR SHOULD be the same as the minimum
866 TTL value field in the zone SOA RR.
868 o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
869 indicate the presence of all types present at the original owner
870 name, except for the types solely contributed by an NSEC3 RR
871 itself. Note that this means that the NSEC3 type itself will
872 never be present in the Type Bit Maps.
874 The following steps describe a method of proper construction of NSEC3
875 RRs. This is not the only such possible method.
877 1. Select the hash algorithm and the values for salt and iterations.
879 2. For each unique original owner name in the zone add an NSEC3 RR.
881 * If Opt-Out is being used, owner names of unsigned delegations
884 * The owner name of the NSEC3 RR is the hash of the original
885 owner name, prepended as a single label to the zone name.
887 * The Next Hashed Owner Name field is left blank for the moment.
889 * If Opt-Out is being used, set the Opt-Out bit to one.
891 * For collision detection purposes, optionally keep track of the
892 original owner name with the NSEC3 RR.
898Laurie, et al. Standards Track [Page 16]
900RFC 5155 NSEC3 March 2008
903 * Additionally, for collision detection purposes, optionally
904 create an additional NSEC3 RR corresponding to the original
905 owner name with the asterisk label prepended (i.e., as if a
906 wildcard existed as a child of this owner name) and keep track
907 of this original owner name. Mark this NSEC3 RR as temporary.
909 3. For each RRSet at the original owner name, set the corresponding
910 bit in the Type Bit Maps field.
912 4. If the difference in number of labels between the apex and the
913 original owner name is greater than 1, additional NSEC3 RRs need
914 to be added for every empty non-terminal between the apex and the
915 original owner name. This process may generate NSEC3 RRs with
916 duplicate hashed owner names. Optionally, for collision
917 detection, track the original owner names of these NSEC3 RRs and
918 create temporary NSEC3 RRs for wildcard collisions in a similar
921 5. Sort the set of NSEC3 RRs into hash order.
923 6. Combine NSEC3 RRs with identical hashed owner names by replacing
924 them with a single NSEC3 RR with the Type Bit Maps field
925 consisting of the union of the types represented by the set of
926 NSEC3 RRs. If the original owner name was tracked, then
927 collisions may be detected when combining, as all of the matching
928 NSEC3 RRs should have the same original owner name. Discard any
929 possible temporary NSEC3 RRs.
931 7. In each NSEC3 RR, insert the next hashed owner name by using the
932 value of the next NSEC3 RR in hash order. The next hashed owner
933 name of the last NSEC3 RR in the zone contains the value of the
934 hashed owner name of the first NSEC3 RR in the hash order.
936 8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
937 Iterations, and Salt fields to the zone apex.
939 If a hash collision is detected, then a new salt has to be chosen,
940 and the signing process restarted.
944 This specification modifies DNSSEC-enabled DNS responses generated by
945 authoritative servers. In particular, it replaces the use of NSEC
946 RRs in such responses with NSEC3 RRs.
954Laurie, et al. Standards Track [Page 17]
956RFC 5155 NSEC3 March 2008
959 In the following response cases, the NSEC RRs dictated by DNSSEC
960 [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
961 Responses that would not contain NSEC RRs are unchanged by this
964 When returning responses containing multiple NSEC3 RRs, all of the
965 NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
966 values. The Flags field value MUST be either zero or one.
9687.2.1. Closest Encloser Proof
970 For many NSEC3 responses a proof of the closest encloser is required.
971 This is a proof that some ancestor of the QNAME is the closest
974 This proof consists of (up to) two different NSEC3 RRs:
976 o An NSEC3 RR that matches the closest (provable) encloser.
978 o An NSEC3 RR that covers the "next closer" name to the closest
981 The first NSEC3 RR essentially proposes a possible closest encloser,
982 and proves that the particular encloser does, in fact, exist. The
983 second NSEC3 RR proves that the possible closest encloser is the
984 closest, and proves that the QNAME (and any ancestors between QNAME
985 and the closest encloser) does not exist.
987 These NSEC3 RRs are collectively referred to as the "closest encloser
988 proof" in the subsequent descriptions.
990 For example, the closest encloser proof for the nonexistent
991 "alpha.beta.gamma.example." owner name might prove that
992 "gamma.example." is the closest encloser. This response would
993 contain the NSEC3 RR that matches "gamma.example.", and would also
994 contain the NSEC3 RR that covers "beta.gamma.example." (which is the
997 It is possible, when using Opt-Out (Section 6), to not be able to
998 prove the actual closest encloser because it is, or is part of an
999 insecure delegation covered by an Opt-Out span. In this case,
1000 instead of proving the actual closest encloser, the closest provable
1001 encloser is used. That is, the closest enclosing authoritative name
1002 is used instead. In this case, the set of NSEC3 RRs used for this
1003 proof is referred to as the "closest provable encloser proof".
1010Laurie, et al. Standards Track [Page 18]
1012RFC 5155 NSEC3 March 2008
10157.2.2. Name Error Responses
1017 To prove the nonexistence of QNAME, a closest encloser proof and an
1018 NSEC3 RR covering the (nonexistent) wildcard RR at the closest
1019 encloser MUST be included in the response. This collection of (up
1020 to) three NSEC3 RRs proves both that QNAME does not exist and that a
1021 wildcard that could have matched QNAME also does not exist.
1023 For example, if "gamma.example." is the closest provable encloser to
1024 QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
1025 the authority section of the response.
10277.2.3. No Data Responses, QTYPE is not DS
1029 The server MUST include the NSEC3 RR that matches QNAME. This NSEC3
1030 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
1031 set in its Type Bit Maps field.
10337.2.4. No Data Responses, QTYPE is DS
1035 If there is an NSEC3 RR that matches QNAME, the server MUST return it
1036 in the response. The bits corresponding with DS and CNAME MUST NOT
1037 be set in the Type Bit Maps field of this NSEC3 RR.
1039 If no NSEC3 RR matches QNAME, the server MUST return a closest
1040 provable encloser proof for QNAME. The NSEC3 RR that covers the
1041 "next closer" name MUST have the Opt-Out bit set (note that this is
1042 true by definition -- if the Opt-Out bit is not set, something has
1045 If a server is authoritative for both sides of a zone cut at QNAME,
1046 the server MUST return the proof from the parent side of the zone
10497.2.5. Wildcard No Data Responses
1051 If there is a wildcard match for QNAME, but QTYPE is not present at
1052 that name, the response MUST include a closest encloser proof for
1053 QNAME and MUST include the NSEC3 RR that matches the wildcard. This
1054 combination proves both that QNAME itself does not exist and that a
1055 wildcard that matches QNAME does exist. Note that the closest
1056 encloser to QNAME MUST be the immediate ancestor of the wildcard RR
1057 (if this is not the case, then something has gone wrong).
1066Laurie, et al. Standards Track [Page 19]
1068RFC 5155 NSEC3 March 2008
10717.2.6. Wildcard Answer Responses
1073 If there is a wildcard match for QNAME and QTYPE, then, in addition
1074 to the expanded wildcard RRSet returned in the answer section of the
1075 response, proof that the wildcard match was valid must be returned.
1077 This proof is accomplished by proving that both QNAME does not exist
1078 and that the closest encloser of the QNAME and the immediate ancestor
1079 of the wildcard are the same (i.e., the correct wildcard matched).
1081 To this end, the NSEC3 RR that covers the "next closer" name of the
1082 immediate ancestor of the wildcard MUST be returned. It is not
1083 necessary to return an NSEC3 RR that matches the closest encloser, as
1084 the existence of this closest encloser is proven by the presence of
1085 the expanded wildcard in the response.
10877.2.7. Referrals to Unsigned Subzones
1089 If there is an NSEC3 RR that matches the delegation name, then that
1090 NSEC3 RR MUST be included in the response. The DS bit in the type
1091 bit maps of the NSEC3 RR MUST NOT be set.
1093 If the zone is Opt-Out, then there may not be an NSEC3 RR
1094 corresponding to the delegation. In this case, the closest provable
1095 encloser proof MUST be included in the response. The included NSEC3
1096 RR that covers the "next closer" name for the delegation MUST have
1097 the Opt-Out flag set to one. (Note that this will be the case unless
1098 something has gone wrong).
11007.2.8. Responding to Queries for NSEC3 Owner Names
1102 The owner names of NSEC3 RRs are not represented in the NSEC3 RR
1103 chain like other owner names. As a result, each NSEC3 owner name is
1104 covered by another NSEC3 RR, effectively negating the existence of
1105 the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR
1106 can be proven by its RRSIG RRSet.
1108 If the following conditions are all true:
1110 o the QNAME equals the owner name of an existing NSEC3 RR, and
1112 o no RR types exist at the QNAME, nor at any descendant of QNAME,
1114 then the response MUST be constructed as a Name Error response
1115 (Section 7.2.2). Or, in other words, the authoritative name server
1116 will act as if the owner name of the NSEC3 RR did not exist.
1122Laurie, et al. Standards Track [Page 20]
1124RFC 5155 NSEC3 March 2008
1127 Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
11307.2.9. Server Response to a Run-Time Collision
1132 If the hash of a non-existing QNAME collides with the owner name of
1133 an existing NSEC3 RR, then the server will be unable to return a
1134 response that proves that QNAME does not exist. In this case, the
1135 server MUST return a response with an RCODE of 2 (server failure).
1137 Note that with the hash algorithm specified in this document, SHA-1,
1138 such collisions are highly unlikely.
11407.3. Secondary Servers
1142 Secondary servers (and perhaps other entities) need to reliably
1143 determine which NSEC3 parameters (i.e., hash, salt, and iterations)
1144 are present at every hashed owner name, in order to be able to choose
1145 an appropriate set of NSEC3 RRs for negative responses. This is
1146 indicated by an NSEC3PARAM RR present at the zone apex.
1148 If there are multiple NSEC3PARAM RRs present, there are multiple
1149 valid NSEC3 chains present. The server must choose one of them, but
1150 may use any criteria to do so.
11527.4. Zones Using Unknown Hash Algorithms
1154 Zones that are signed according to this specification, but are using
1155 an unrecognized NSEC3 hash algorithm value, cannot be effectively
1156 served. Such zones SHOULD be rejected when loading. Servers SHOULD
1157 respond with RCODE=2 (server failure) responses when handling queries
1158 that would fall under such zones.
1162 A zone signed using NSEC3 may accept dynamic updates [RFC2136].
1163 However, NSEC3 introduces some special considerations for dynamic
1166 Adding and removing names in a zone MUST account for the creation or
1167 removal of empty non-terminals.
1169 o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
1170 corresponding to empty non-terminals created by that name MUST be
1171 removed. Note that more than one name may be asserting the
1172 existence of a particular empty non-terminal.
1178Laurie, et al. Standards Track [Page 21]
1180RFC 5155 NSEC3 March 2008
1183 o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
1184 MUST also be added for any empty non-terminals that are created.
1185 That is, if there is not an existing NSEC3 RR matching an empty
1186 non-terminal, it must be created and added.
1188 The presence of Opt-Out in a zone means that some additions or
1189 delegations of names will not require changes to the NSEC3 RRs in a
1192 o When removing a delegation RRSet, if that delegation does not have
1193 a matching NSEC3 RR, then it was opted out. In this case, nothing
1194 further needs to be done.
1196 o When adding a delegation RRSet, if the "next closer" name of the
1197 delegation is covered by an existing Opt-Out NSEC3 RR, then the
1198 delegation MAY be added without modifying the NSEC3 RRs in the
1201 The presence of Opt-Out in a zone means that when adding or removing
1202 NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
1203 modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of
1204 basic rules to resolve the ambiguity.
1206 The central concept to these rules is that the state of the Opt-Out
1207 flag of the covering NSEC3 RR is preserved.
1209 o When removing an NSEC3 RR, the value of the Opt-Out flag for the
1210 previous NSEC3 RR (the one whose next hashed owner name is
1211 modified) should not be changed.
1213 o When adding an NSEC3 RR, the value of the Opt-Out flag is set to
1214 the value of the Opt-Out flag of the NSEC3 RR that previously
1215 covered the owner name of the NSEC3 RR. That is, the now previous
1218 If the zone in question is consistent with its use of the Opt-Out
1219 flag (that is, all NSEC3 RRs in the zone have the same value for the
1220 flag) then these rules will retain that consistency. If the zone is
1221 not consistent in the use of the flag (i.e., a partially Opt-Out
1222 zone), then these rules will not retain the same pattern of use of
1225 For zones that partially use the Opt-Out flag, if there is a logical
1226 pattern for that use, the pattern could be maintained by using a
1227 local policy on the server.
1234Laurie, et al. Standards Track [Page 22]
1236RFC 5155 NSEC3 March 2008
12398. Validator Considerations
12418.1. Responses with Unknown Hash Types
1243 A validator MUST ignore NSEC3 RRs with unknown hash types. The
1244 practical result of this is that responses containing only such NSEC3
1245 RRs will generally be considered bogus.
12478.2. Verifying NSEC3 RRs
1249 A validator MUST ignore NSEC3 RRs with a Flag fields value other than
1252 A validator MAY treat a response as bogus if the response contains
1253 NSEC3 RRs that contain different values for hash algorithm,
1254 iterations, or salt from each other for that zone.
12568.3. Closest Encloser Proof
1258 In order to verify a closest encloser proof, the validator MUST find
1259 the longest name, X, such that
1261 o X is an ancestor of QNAME that is matched by an NSEC3 RR present
1262 in the response. This is a candidate for the closest encloser,
1265 o The name one label longer than X (but still an ancestor of -- or
1266 equal to -- QNAME) is covered by an NSEC3 RR present in the
1269 One possible algorithm for verifying this proof is as follows:
1271 1. Set SNAME=QNAME. Clear the flag.
1273 2. Check whether SNAME exists:
1275 * If there is no NSEC3 RR in the response that matches SNAME
1276 (i.e., an NSEC3 RR whose owner name is the same as the hash of
1277 SNAME, prepended as a single label to the zone name), clear
1280 * If there is an NSEC3 RR in the response that covers SNAME, set
1283 * If there is a matching NSEC3 RR in the response and the flag
1284 was set, then the proof is complete, and SNAME is the closest
1290Laurie, et al. Standards Track [Page 23]
1292RFC 5155 NSEC3 March 2008
1295 * If there is a matching NSEC3 RR in the response, but the flag
1296 is not set, then the response is bogus.
1298 3. Truncate SNAME by one label from the left, go to step 2.
1300 Once the closest encloser has been discovered, the validator MUST
1301 check that the NSEC3 RR that has the closest encloser as the original
1302 owner name is from the proper zone. The DNAME type bit must not be
1303 set and the NS type bit may only be set if the SOA type bit is set.
1304 If this is not the case, it would be an indication that an attacker
1305 is using them to falsely deny the existence of RRs for which the
1306 server is not authoritative.
1308 In the following descriptions, the phrase "a closest (provable)
1309 encloser proof for X" means that the algorithm above (or an
1310 equivalent algorithm) proves that X does not exist by proving that an
1311 ancestor of X is its closest encloser.
13138.4. Validating Name Error Responses
1315 A validator MUST verify that there is a closest encloser proof for
1316 QNAME present in the response and that there is an NSEC3 RR that
1317 covers the wildcard at the closest encloser (i.e., the name formed by
1318 prepending the asterisk label to the closest encloser).
13208.5. Validating No Data Responses, QTYPE is not DS
1322 The validator MUST verify that an NSEC3 RR that matches QNAME is
1323 present and that both the QTYPE and the CNAME type are not set in its
1324 Type Bit Maps field.
1326 Note that this test also covers the case where the NSEC3 RR exists
1327 because it corresponds to an empty non-terminal, in which case the
1328 NSEC3 RR will have an empty Type Bit Maps field.
13308.6. Validating No Data Responses, QTYPE is DS
1332 If there is an NSEC3 RR that matches QNAME present in the response,
1333 then that NSEC3 RR MUST NOT have the bits corresponding to DS and
1334 CNAME set in its Type Bit Maps field.
1336 If there is no such NSEC3 RR, then the validator MUST verify that a
1337 closest provable encloser proof for QNAME is present in the response,
1338 and that the NSEC3 RR that covers the "next closer" name has the Opt-
1346Laurie, et al. Standards Track [Page 24]
1348RFC 5155 NSEC3 March 2008
13518.7. Validating Wildcard No Data Responses
1353 The validator MUST verify a closest encloser proof for QNAME and MUST
1354 find an NSEC3 RR present in the response that matches the wildcard
1355 name generated by prepending the asterisk label to the closest
1356 encloser. Furthermore, the bits corresponding to both QTYPE and
1357 CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
13598.8. Validating Wildcard Answer Responses
1361 The verified wildcard answer RRSet in the response provides the
1362 validator with a (candidate) closest encloser for QNAME. This
1363 closest encloser is the immediate ancestor to the generating
1366 Validators MUST verify that there is an NSEC3 RR that covers the
1367 "next closer" name to QNAME present in the response. This proves
1368 that QNAME itself did not exist and that the correct wildcard was
1369 used to generate the response.
13718.9. Validating Referrals to Unsigned Subzones
1373 The delegation name in a referral is the owner name of the NS RRSet
1374 present in the authority section of the referral response.
1376 If there is an NSEC3 RR present in the response that matches the
1377 delegation name, then the validator MUST ensure that the NS bit is
1378 set and that the DS bit is not set in the Type Bit Maps field of the
1379 NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from
1380 the correct (i.e., parent) zone. This is done by ensuring that the
1381 SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
1383 Note that the presence of an NS bit implies the absence of a DNAME
1384 bit, so there is no need to check for the DNAME bit in the Type Bit
1385 Maps field of the NSEC3 RR.
1387 If there is no NSEC3 RR present that matches the delegation name,
1388 then the validator MUST verify a closest provable encloser proof for
1389 the delegation name. The validator MUST verify that the Opt-Out bit
1390 is set in the NSEC3 RR that covers the "next closer" name to the
1402Laurie, et al. Standards Track [Page 25]
1404RFC 5155 NSEC3 March 2008
14079. Resolver Considerations
14099.1. NSEC3 Resource Record Caching
1411 Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
1412 when returning responses that contain them. In DNSSEC [RFC4035], in
1413 many cases it is possible to find the correct NSEC RR to return in a
1414 response by name (e.g., when returning a referral, the NSEC RR will
1415 always have the same owner name as the delegation). With this
1416 specification, that will not be true, nor will a cache be able to
1417 calculate the name(s) of the appropriate NSEC3 RR(s).
1418 Implementations may need to use new methods for caching and
1419 retrieving NSEC3 RRs.
14219.2. Use of the AD Bit
1423 The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
1424 response containing a closest (provable) encloser proof in which the
1425 NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
1427 This rule is based on what this closest encloser proof actually
1428 proves: names that would be covered by the Opt-Out NSEC3 RR may or
1429 may not exist as insecure delegations. As such, not all the data in
1430 responses containing such closest encloser proofs will have been
1431 cryptographically verified, so the AD bit cannot be set.
143310. Special Considerations
143510.1. Domain Name Length Restrictions
1437 Zones signed using this specification have additional domain name
1438 length restrictions imposed upon them. In particular, zones with
1439 names that, when converted into hashed owner names exceed the 255
1440 octet length limit imposed by [RFC1035], cannot use this
1443 The actual maximum length of a domain name in a particular zone
1444 depends on both the length of the zone name (versus the whole domain
1445 name) and the particular hash function used.
1447 As an example, SHA-1 produces a hash of 160 bits. The base-32
1448 encoding of 160 bits results in 32 characters. The 32 characters are
1449 prepended to the name of the zone as a single label, which includes a
1450 length field of a single octet. The maximum length of the zone name,
1451 when using SHA-1, is 222 octets (255 - 33).
1458Laurie, et al. Standards Track [Page 26]
1460RFC 5155 NSEC3 March 2008
146310.2. DNAME at the Zone Apex
1465 The DNAME specification in Section 3 of [RFC2672] has a 'no-
1466 descendants' limitation. If a DNAME RR is present at node N, there
1467 MUST be no data at any descendant of N.
1469 If N is the apex of the zone, there will be NSEC3 and RRSIG types
1470 present at descendants of N. This specification updates the DNAME
1471 specification to allow NSEC3 and RRSIG types at descendants of the
1472 apex regardless of the existence of DNAME at the apex.
1476 Setting the number of iterations used allows the zone owner to choose
1477 the cost of computing a hash, and therefore the cost of generating a
1478 dictionary. Note that this is distinct from the effect of salt,
1479 which prevents the use of a single precomputed dictionary for all
1482 Obviously the number of iterations also affects the zone owner's cost
1483 of signing and serving the zone as well as the validator's cost of
1484 verifying responses from the zone. We therefore impose an upper
1485 limit on the number of iterations. We base this on the number of
1486 iterations that approximates the cost of verifying an RRSet.
1488 The limits, therefore, are based on the size of the smallest zone
1489 signing key, rounded up to the nearest table value (or rounded down
1490 if the key is larger than the largest table value).
1492 A zone owner MUST NOT use a value higher than shown in the table
1493 below for iterations for the given key size. A resolver MAY treat a
1494 response with a higher value as insecure, after the validator has
1495 verified that the signature over the NSEC3 RR is correct.
1497 +----------+------------+
1498 | Key Size | Iterations |
1499 +----------+------------+
1503 +----------+------------+
1505 This table is based on an approximation of the ratio between the cost
1506 of an SHA-1 calculation and the cost of an RSA verification for keys
1507 of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
1514Laurie, et al. Standards Track [Page 27]
1516RFC 5155 NSEC3 March 2008
1519 The ratio between SHA-1 calculation and DSA verification is higher
1520 (1500 to 1 for keys of size 1024). A higher iteration count degrades
1521 performance, while DSA verification is already more expensive than
1522 RSA for the same key size. Therefore the values in the table MUST be
1523 used independent of the key algorithm.
152510.4. Transitioning a Signed Zone from NSEC to NSEC3
1527 When transitioning an already signed and trusted zone to this
1528 specification, care must be taken to prevent client validation
1529 failures during the process.
1531 The basic procedure is as follows:
1533 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases
1534 described in Section 2. The actual method for safely and
1535 securely changing the DNSKEY RRSet of the zone is outside the
1536 scope of this specification. However, the end result MUST be
1537 that all DS RRs in the parent use the specified algorithm
1540 After this transition is complete, all NSEC3-unaware clients will
1541 treat the zone as insecure. At this point, the authoritative
1542 server still returns negative and wildcard responses that contain
1545 2. Add signed NSEC3 RRs to the zone, either incrementally or all at
1546 once. If adding incrementally, then the last RRSet added MUST be
1547 the NSEC3PARAM RRSet.
1549 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to
1550 serving negative and wildcard responses with NSEC3 RRs according
1551 to this specification.
1553 4. Remove the NSEC RRs either incrementally or all at once.
155510.5. Transitioning a Signed Zone from NSEC3 to NSEC
1557 To safely transition back to a DNSSEC [RFC4035] signed zone, simply
1558 reverse the procedure above:
1560 1. Add NSEC RRs incrementally or all at once.
1562 2. Remove the NSEC3PARAM RRSet. This will signal the server to use
1563 the NSEC RRs for negative and wildcard responses.
1565 3. Remove the NSEC3 RRs either incrementally or all at once.
1570Laurie, et al. Standards Track [Page 28]
1572RFC 5155 NSEC3 March 2008
1575 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
1576 After this transition is complete, all NSEC3-unaware clients will
1577 treat the zone as secure.
157911. IANA Considerations
1581 Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
1582 parameter, this document does not define a particular mechanism for
1583 safely transitioning from one NSEC3 hash algorithm to another. When
1584 specifying a new hash algorithm for use with NSEC3, a transition
1585 mechanism MUST also be defined.
1587 This document updates the IANA registry "DOMAIN NAME SYSTEM
1588 PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
1589 registry "TYPES", by defining two new types. Section 3 defines the
1590 NSEC3 RR type 50. Section 4 defines the NSEC3PARAM RR type 51.
1592 This document updates the IANA registry "DNS SECURITY ALGORITHM
1593 NUMBERS -- per [RFC4035]"
1594 (http://www.iana.org/assignments/dns-sec-alg-numbers). Section 2
1595 defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
1596 respectively existing registrations DSA and RSASHA1 in combination
1597 with NSEC3 hash algorithm SHA1.
1599 Since these algorithm numbers are aliases for existing DNSKEY
1600 algorithm numbers, the flags that exist for the original algorithm
1601 are valid for the alias algorithm.
1603 This document creates a new IANA registry for NSEC3 flags. This
1604 registry is named "DNSSEC NSEC3 Flags". The initial contents of this
1608 +---+---+---+---+---+---+---+---+
1611 +---+---+---+---+---+---+---+---+
1613 bit 7 is the Opt-Out flag.
1615 bits 0 - 6 are available for assignment.
1617 Assignment of additional NSEC3 Flags in this registry requires IETF
1618 Standards Action [RFC2434].
1620 This document creates a new IANA registry for NSEC3PARAM flags. This
1621 registry is named "DNSSEC NSEC3PARAM Flags". The initial contents of
1626Laurie, et al. Standards Track [Page 29]
1628RFC 5155 NSEC3 March 2008
1632 +---+---+---+---+---+---+---+---+
1634 +---+---+---+---+---+---+---+---+
1636 bit 7 is reserved and must be 0.
1638 bits 0 - 6 are available for assignment.
1640 Assignment of additional NSEC3PARAM Flags in this registry requires
1641 IETF Standards Action [RFC2434].
1643 Finally, this document creates a new IANA registry for NSEC3 hash
1644 algorithms. This registry is named "DNSSEC NSEC3 Hash Algorithms".
1645 The initial contents of this registry are:
1651 2-255 Available for assignment.
1653 Assignment of additional NSEC3 hash algorithms in this registry
1654 requires IETF Standards Action [RFC2434].
165612. Security Considerations
165812.1. Hashing Considerations
166012.1.1. Dictionary Attacks
1662 The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
1663 attacker retrieves all the NSEC3 RRs, then calculates the hashes of
1664 all likely domain names, comparing against the hashes found in the
1665 NSEC3 RRs, and thus enumerating the zone). These are substantially
1666 more expensive than enumerating the original NSEC RRs would have
1667 been, and in any case, such an attack could also be used directly
1668 against the name server itself by performing queries for all likely
1669 names, though this would obviously be more detectable. The expense
1670 of this off-line attack can be chosen by setting the number of
1671 iterations in the NSEC3 RR.
1673 Zones are also susceptible to a pre-calculated dictionary attack --
1674 that is, a list of hashes for all likely names is computed once, then
1675 NSEC3 RR is scanned periodically and compared against the precomputed
1676 hashes. This attack is prevented by changing the salt on a regular
1682Laurie, et al. Standards Track [Page 30]
1684RFC 5155 NSEC3 March 2008
1687 The salt SHOULD be at least 64 bits long and unpredictable, so that
1688 an attacker cannot anticipate the value of the salt and compute the
1689 next set of dictionaries before the zone is published.
1693 Hash collisions between QNAME and the owner name of an NSEC3 RR may
1694 occur. When they do, it will be impossible to prove the non-
1695 existence of the colliding QNAME. However, with SHA-1, this is
1696 highly unlikely (on the order of 1 in 2^160). Note that DNSSEC
1697 already relies on the presumption that a cryptographic hash function
1698 is second pre-image resistant, since these hash functions are used
1699 for generating and validating signatures and DS RRs.
170112.1.3. Transitioning to a New Hash Algorithm
1703 Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
1704 parameter, this document does not define a particular mechanism for
1705 safely transitioning from one NSEC3 hash algorithm to another. When
1706 specifying a new hash algorithm for use with NSEC3, a transition
1707 mechanism MUST also be defined. It is possible that the only
1708 practical and palatable transition mechanisms may require an
1709 intermediate transition to an insecure state, or to a state that uses
1710 NSEC records instead of NSEC3.
171212.1.4. Using High Iteration Values
1714 Since validators should treat responses containing NSEC3 RRs with
1715 high iteration values as insecure, presence of just one signed NSEC3
1716 RR with a high iteration value in a zone provides attackers with a
1717 possible downgrade attack.
1719 The attack is simply to remove any existing NSEC3 RRs from a
1720 response, and replace or add a single (or multiple) NSEC3 RR that
1721 uses a high iterations value to the response. Validators will then
1722 be forced to treat the response as insecure. This attack would be
1723 effective only when all of following conditions are met:
1725 o There is at least one signed NSEC3 RR that uses a high iterations
1726 value present in the zone.
1728 o The attacker has access to one or more of these NSEC3 RRs. This
1729 is trivially true when the NSEC3 RRs with high iteration values
1730 are being returned in typical responses, but may also be true if
1731 the attacker can access the zone via AXFR or IXFR queries, or any
1738Laurie, et al. Standards Track [Page 31]
1740RFC 5155 NSEC3 March 2008
1743 Using a high number of iterations also introduces an additional
1744 denial-of-service opportunity against servers, since servers must
1745 calculate several hashes per negative or wildcard response.
174712.2. Opt-Out Considerations
1749 The Opt-Out Flag (O) allows for unsigned names, in the form of
1750 delegations to unsigned zones, to exist within an otherwise signed
1751 zone. All unsigned names are, by definition, insecure, and their
1752 validity or existence cannot be cryptographically proven.
1756 o Resource records with unsigned names (whether existing or not)
1757 suffer from the same vulnerabilities as RRs in an unsigned zone.
1758 These vulnerabilities are described in more detail in [RFC3833]
1759 (note in particular Section 2.3, "Name Chaining" and Section 2.6,
1760 "Authenticated Denial of Domain Names").
1762 o Resource records with signed names have the same security whether
1763 or not Opt-Out is used.
1765 Note that with or without Opt-Out, an insecure delegation may be
1766 undetectably altered by an attacker. Because of this, the primary
1767 difference in security when using Opt-Out is the loss of the ability
1768 to prove the existence or nonexistence of an insecure delegation
1769 within the span of an Opt-Out NSEC3 RR.
1771 In particular, this means that a malicious entity may be able to
1772 insert or delete RRs with unsigned names. These RRs are normally NS
1773 RRs, but this also includes signed wildcard expansions (while the
1774 wildcard RR itself is signed, its expanded name is an unsigned name).
1776 Note that being able to add a delegation is functionally equivalent
1777 to being able to add any RR type: an attacker merely has to forge a
1778 delegation to name server under his/her control and place whatever
1779 RRs needed at the subzone apex.
1781 While in particular cases, this issue may not present a significant
1782 security problem, in general it should not be lightly dismissed.
1783 Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
1784 In particular, zone signing tools SHOULD NOT default to using Opt-
1785 Out, and MAY choose to not support Opt-Out at all.
1794Laurie, et al. Standards Track [Page 32]
1796RFC 5155 NSEC3 March 2008
179912.3. Other Considerations
1801 Walking the NSEC3 RRs will reveal the total number of RRs in the zone
1802 (plus empty non-terminals), and also what types there are. This
1803 could be mitigated by adding dummy entries, but certainly an upper
1804 limit can always be found.
180813.1. Normative References
1810 [RFC1034] Mockapetris, P., "Domain names - concepts and
1811 facilities", STD 13, RFC 1034, November 1987.
1813 [RFC1035] Mockapetris, P., "Domain names - implementation and
1814 specification", STD 13, RFC 1035, November 1987.
1816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1817 Requirement Levels", BCP 14, RFC 2119, March 1997.
1819 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1820 "Dynamic Updates in the Domain Name System (DNS
1821 UPDATE)", RFC 2136, April 1997.
1823 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1824 Specification", RFC 2181, July 1997.
1826 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1827 NCACHE)", RFC 2308, March 1998.
1829 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
1830 Writing an IANA Considerations Section in RFCs",
1831 BCP 26, RFC 2434, October 1998.
1833 [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
1834 "Domain Name System (DNS) IANA Considerations",
1835 BCP 42, RFC 2929, September 2000.
1837 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
1838 Record (RR) Types", RFC 3597, September 2003.
1840 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D.,
1841 and S. Rose, "DNS Security Introduction and
1842 Requirements", RFC 4033, March 2005.
1844 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D.,
1845 and S. Rose, "Resource Records for the DNS Security
1846 Extensions", RFC 4034, March 2005.
1850Laurie, et al. Standards Track [Page 33]
1852RFC 5155 NSEC3 March 2008
1855 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D.,
1856 and S. Rose, "Protocol Modifications for the DNS
1857 Security Extensions", RFC 4035, March 2005.
1859 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
1860 Encodings", RFC 4648, October 2006.
186213.2. Informative References
1864 [DNSEXT-NO] Josefsson, S., "Authenticating Denial of Existence
1865 in DNS with Minimum Disclosure", Work in Progress,
1868 [DNSEXT-NSEC2v2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
1869 Work in Progress, December 2004.
1871 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
1872 RFC 2672, August 1999.
1874 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
1875 Specification Version 2.0", RFC 2898,
1878 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
1879 Domain Name System (DNS)", RFC 3833, August 2004.
1881 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain
1882 Name System", RFC 4592, July 2006.
1884 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS
1885 Security (DNSSEC) Opt-In", RFC 4956, July 2007.
1906Laurie, et al. Standards Track [Page 34]
1908RFC 5155 NSEC3 March 2008
1911Appendix A. Example Zone
1913 This is a zone showing its NSEC3 RRs. They can also be used as test
1914 vectors for the hash algorithm.
1916 The overall TTL and class are specified in the SOA RR, and are
1917 subsequently omitted for clarity.
1919 The zone is preceded by a list that contains the hashes of the
1920 original ownernames.
1922 ; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
1923 ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl
1924 ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi
1925 ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
1926 ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r
1927 ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
1928 ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
1929 ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
1930 ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc
1931 ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
1932 ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv
1933 ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
1934 ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
1935 example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 (
1937 RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
1939 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
1940 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
1944 RRSIG NS 7 1 3600 20150420235959 20051021000000 (
1946 PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
1947 qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
1950 RRSIG MX 7 1 3600 20150420235959 20051021000000 (
1952 GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
1953 9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
1955 DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
1956 sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
1957 TY4hHn9npWFRw5BYubE= )
1962Laurie, et al. Standards Track [Page 35]
1964RFC 5155 NSEC3 March 2008
1967 DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
1968 j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
1969 AbsUdblMFin8CVF3n4s= )
1970 RRSIG DNSKEY 7 1 3600 20150420235959 (
1971 20051021000000 12708 example.
1972 AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
1973 uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
1975 NSEC3PARAM 1 0 12 aabbccdd
1976 RRSIG NSEC3PARAM 7 1 3600 20150420235959 (
1977 20051021000000 40430 example.
1978 C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
1979 rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
1981 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
1982 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
1983 SOA NSEC3PARAM RRSIG )
1984 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
1986 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
1987 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
1989 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
1990 RRSIG A 7 2 3600 20150420235959 20051021000000 (
1992 h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
1993 K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
1995 NSEC3 1 1 12 aabbccdd (
1996 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
1997 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
1999 OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
2000 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
2002 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
2003 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
2004 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2006 KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
2007 VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
2009 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2010 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
2018Laurie, et al. Standards Track [Page 36]
2020RFC 5155 NSEC3 March 2008
2023 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2025 g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2026 Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2028 a.example. NS ns1.a.example.
2031 3079F1593EBAD6DC121E202A8B766A6A4837206C )
2032 RRSIG DS 7 2 3600 20150420235959 20051021000000 (
2034 XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
2035 M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
2037 ns1.a.example. A 192.0.2.5
2038 ns2.a.example. A 192.0.2.6
2039 ai.example. A 192.0.2.9
2040 RRSIG A 7 2 3600 20150420235959 20051021000000 (
2042 hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
2043 tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
2045 HINFO "KLH-10" "ITS"
2046 RRSIG HINFO 7 2 3600 20150420235959 20051021000000 (
2048 Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
2049 enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
2051 AAAA 2001:db8:0:0:0:0:f00:baa9
2052 RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
2054 LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
2055 uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
2057 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
2058 gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
2059 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2061 ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
2062 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
2064 c.example. NS ns1.c.example.
2066 ns1.c.example. A 192.0.2.7
2067 ns2.c.example. A 192.0.2.8
2068 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
2069 ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
2074Laurie, et al. Standards Track [Page 37]
2076RFC 5155 NSEC3 March 2008
2079 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2081 IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
2082 LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
2084 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
2085 k8udemvp1j2f7eg6jebps17vp3n8i58h )
2086 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2088 gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
2089 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
2091 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
2092 kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
2093 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2095 FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
2096 S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
2098 kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
2099 q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
2100 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2102 VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
2103 6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
2105 ns1.example. A 192.0.2.1
2106 RRSIG A 7 2 3600 20150420235959 20051021000000 (
2108 bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
2109 kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
2111 ns2.example. A 192.0.2.2
2112 RRSIG A 7 2 3600 20150420235959 20051021000000 (
2114 ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
2115 zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
2117 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2118 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2119 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2121 hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2122 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2130Laurie, et al. Standards Track [Page 38]
2132RFC 5155 NSEC3 March 2008
2135 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
2136 t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
2137 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2139 aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
2140 ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
2142 t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
2143 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
2145 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2147 RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
2148 fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
2150 *.w.example. MX 1 ai.example.
2151 RRSIG MX 7 2 3600 20150420235959 20051021000000 (
2153 CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
2154 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
2156 x.w.example. MX 1 xx.example.
2157 RRSIG MX 7 3 3600 20150420235959 20051021000000 (
2159 IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
2160 QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
2162 x.y.w.example. MX 1 xx.example.
2163 RRSIG MX 7 4 3600 20150420235959 20051021000000 (
2165 MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
2166 nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
2168 xx.example. A 192.0.2.10
2169 RRSIG A 7 2 3600 20150420235959 20051021000000 (
2171 T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
2172 YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
2174 HINFO "KLH-10" "TOPS-20"
2175 RRSIG HINFO 7 2 3600 20150420235959 20051021000000 (
2177 KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
2178 FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
2180 AAAA 2001:db8:0:0:0:0:f00:baaa
2186Laurie, et al. Standards Track [Page 39]
2188RFC 5155 NSEC3 March 2008
2191 RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
2193 IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
2194 uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
2197Appendix B. Example Responses
2199 The examples in this section show response messages using the signed
2200 zone example in Appendix A.
2204 An authoritative name error. The NSEC3 RRs prove that the name does
2205 not exist and that there is no wildcard RR that should have been
2208;; Header: QR AA DO RCODE=3
2211a.c.x.w.example. IN A
2218example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2220example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2222 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2223 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2226;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
2227;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
22290p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2230 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2231 SOA NSEC3PARAM RRSIG )
22320p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
2233 20150420235959 20051021000000 40430 example.
2234 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2235 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2242Laurie, et al. Standards Track [Page 40]
2244RFC 5155 NSEC3 March 2008
2247;; NSEC3 RR that matches the closest encloser (x.w.example)
2248;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
2250b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
2251 gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
2252b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
2253 20150420235959 20051021000000 40430 example.
2254 ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
2255 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
2258;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
2259;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
226135mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2262 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
226335mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
2264 20150420235959 20051021000000 40430 example.
2265 g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2266 Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2272 The query returned three NSEC3 RRs that prove that the requested data
2273 does not exist and that no wildcard expansion applies. The negative
2274 response is authenticated by verifying the NSEC3 RRs. The
2275 corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
2276 "example" DNSKEY of algorithm 7 and with key tag 40430. The resolver
2277 needs the corresponding DNSKEY RR in order to authenticate this
2280 One of the owner names of the NSEC3 RRs matches the closest encloser.
2281 One of the NSEC3 RRs prove that there exists no longer name. One of
2282 the NSEC3 RRs prove that there exists no wildcard RRSets that should
2283 have been expanded. The closest encloser can be found by applying
2284 the algorithm in Section 8.3.
2286 In the above example, the name 'x.w.example' hashes to
2287 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might
2288 be the closest encloser. To prove that 'c.x.w.example' and
2289 '*.x.w.example' do not exist, these names are hashed to,
2290 respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
2291 '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs
2292 prove that these hashed owner names do not exist.
2298Laurie, et al. Standards Track [Page 41]
2300RFC 5155 NSEC3 March 2008
2305 A "no data" response. The NSEC3 RR proves that the name exists and
2306 that the requested RR type does not.
2308;; Header: QR AA DO RCODE=0
2317example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2319example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2321 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2322 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2325;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
23272t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
2328 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
23292t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
2330 20150420235959 20051021000000 40430 example.
2331 OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
2332 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
2337 The query returned an NSEC3 RR that proves that the requested name
2338 exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
2339 but the requested RR type does not exist (type MX is absent in the
2340 type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
2341 also absent in the type code list of the NSEC3 RR).
2354Laurie, et al. Standards Track [Page 42]
2356RFC 5155 NSEC3 March 2008
2359B.2.1. No Data Error, Empty Non-Terminal
2361 A "no data" response because of an empty non-terminal. The NSEC3 RR
2362 proves that the name exists and that the requested RR type does not.
2364 ;; Header: QR AA DO RCODE=0
2373 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2375 example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2377 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2378 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2381 ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
2383 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
2384 k8udemvp1j2f7eg6jebps17vp3n8i58h )
2385 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
2386 20150420235959 20051021000000 40430 example.
2387 gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
2388 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
2394 The query returned an NSEC3 RR that proves that the requested name
2395 exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
2396 but the requested RR type does not exist (Type A is absent in the
2397 Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty
2398 non-terminal proof using NSECs, this is identical to a No Data Error.
2399 This example is solely mentioned to be complete.
2410Laurie, et al. Standards Track [Page 43]
2412RFC 5155 NSEC3 March 2008
2415B.3. Referral to an Opt-Out Unsigned Zone
2417 The NSEC3 RRs prove that nothing for this delegation was signed.
2418 There is no proof that the unsigned delegation exists.
2420 ;; Header: QR DO RCODE=0
2429 c.example. NS ns1.c.example.
2432 ;; NSEC3 RR that covers the "next closer" name (c.example)
2433 ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
2435 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2436 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
2437 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
2438 20150420235959 20051021000000 40430 example.
2439 g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2440 Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2443 ;; NSEC3 RR that matches the closest encloser (example)
2444 ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
2446 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2447 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2448 SOA NSEC3PARAM RRSIG )
2449 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
2450 20150420235959 20051021000000 40430 example.
2451 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2452 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2456 ns1.c.example. A 192.0.2.7
2457 ns2.c.example. A 192.0.2.8
2459 The query returned a referral to the unsigned "c.example." zone. The
2460 response contains the closest provable encloser of "c.example" to be
2461 "example", since the hash of "c.example"
2466Laurie, et al. Standards Track [Page 44]
2468RFC 5155 NSEC3 March 2008
2471 ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
2472 and its Opt-Out bit is set.
2474B.4. Wildcard Expansion
2476 A query that was answered with a response containing a wildcard
2477 expansion. The label count in the RRSIG RRSet in the answer section
2478 indicates that a wildcard RRSet was expanded to produce this
2479 response, and the NSEC3 RR proves that no "next closer" name exists
2482 ;; Header: QR AA DO RCODE=0
2485 a.z.w.example. IN MX
2488 a.z.w.example. MX 1 ai.example.
2489 a.z.w.example. RRSIG MX 7 2 3600 20150420235959 20051021000000 (
2491 CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
2492 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
2496 example. NS ns1.example.
2497 example. NS ns2.example.
2498 example. RRSIG NS 7 1 3600 20150420235959 20051021000000 (
2500 PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
2501 qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
2504 ;; NSEC3 RR that covers the "next closer" name (z.w.example)
2505 ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
2507 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2508 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2509 q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
2510 20150420235959 20051021000000 40430 example.
2511 hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2512 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2522Laurie, et al. Standards Track [Page 45]
2524RFC 5155 NSEC3 March 2008
2528 ai.example. A 192.0.2.9
2529 ai.example. RRSIG A 7 2 3600 20150420235959 20051021000000 (
2531 hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
2532 tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
2534 ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9
2535 ai.example. RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
2537 LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
2538 uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
2541 The query returned an answer that was produced as a result of a
2542 wildcard expansion. The answer section contains a wildcard RRSet
2543 expanded as it would be in a traditional DNS response. The RRSIG
2544 Labels field value of 2 indicates that the answer is the result of a
2545 wildcard expansion, as the "a.z.w.example" name contains 4 labels.
2546 This also shows that "w.example" exists, so there is no need for an
2547 NSEC3 RR that matches the closest encloser.
2549 The NSEC3 RR proves that no closer match could have been used to
2552B.5. Wildcard No Data Error
2554 A "no data" response for a name covered by a wildcard. The NSEC3 RRs
2555 prove that the matching wildcard name does not have any RRs of the
2556 requested type and that no closer match exists in the zone.
2558 ;; Header: QR AA DO RCODE=0
2561 a.z.w.example. IN AAAA
2567 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2569 example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2571 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2572 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2578Laurie, et al. Standards Track [Page 46]
2580RFC 5155 NSEC3 March 2008
2583 ;; NSEC3 RR that matches the closest encloser (w.example)
2584 ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
2586 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
2587 kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
2588 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
2589 20150420235959 20051021000000 40430 example.
2590 FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
2591 S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
2594 ;; NSEC3 RR that covers the "next closer" name (z.w.example)
2595 ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
2597 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2598 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2599 q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
2600 20150420235959 20051021000000 40430 example.
2601 hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2602 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2605 ;; NSEC3 RR that matches a wildcard at the closest encloser.
2606 ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
2608 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
2609 t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
2610 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
2611 20150420235959 20051021000000 40430 example.
2612 aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
2613 ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
2619 The query returned the NSEC3 RRs that prove that the requested data
2620 does not exist and no wildcard RR applies.
2634Laurie, et al. Standards Track [Page 47]
2636RFC 5155 NSEC3 March 2008
2639B.6. DS Child Zone No Data Error
2641 A "no data" response for a QTYPE=DS query that was mistakenly sent to
2642 a name server for the child zone.
2644;; Header: QR AA DO RCODE=0
2653example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2655example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2657 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2658 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2661;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
26630p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2664 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2665 SOA NSEC3PARAM RRSIG )
26660p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
2667 20150420235959 20051021000000 40430 example.
2668 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2669 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2675 The query returned an NSEC3 RR showing that the requested was
2676 answered by the server authoritative for the zone "example". The
2677 NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
2678 RR is from the apex of the child, not from the zone cut of the
2679 parent. Queries for the "example" DS RRSet should be sent to the
2680 parent servers (which are in this case the root servers).
2682Appendix C. Special Considerations
2684 The following paragraphs clarify specific behavior and explain
2685 special considerations for implementations.
2690Laurie, et al. Standards Track [Page 48]
2692RFC 5155 NSEC3 March 2008
2697 Augmenting original owner names with salt before hashing increases
2698 the cost of a dictionary of pre-generated hash-values. For every bit
2699 of salt, the cost of a precomputed dictionary doubles (because there
2700 must be an entry for each word combined with each possible salt
2701 value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
2702 salt, multiplying the cost by 2^2040. This means that an attacker
2703 must, in practice, recompute the dictionary each time the salt is
2706 Including a salt, regardless of size, does not affect the cost of
2707 constructing NSEC3 RRs. It does increase the size of the NSEC3 RR.
2709 There MUST be at least one complete set of NSEC3 RRs for the zone
2710 using the same salt value.
2712 The salt SHOULD be changed periodically to prevent pre-computation
2713 using a single salt. It is RECOMMENDED that the salt be changed for
2716 Note that this could cause a resolver to see RRs with different salt
2717 values for the same zone. This is harmless, since each RR stands
2718 alone (that is, it denies the set of owner names whose hashes, using
2719 the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
2720 RR) -- it is only the server that needs a complete set of NSEC3 RRs
2721 with the same salt in order to be able to answer every possible
2724 There is no prohibition with having NSEC3 RRs with different salts
2725 within the same zone. However, in order for authoritative servers to
2726 be able to consistently find covering NSEC3 RRs, the authoritative
2727 server MUST choose a single set of parameters (algorithm, salt, and
2728 iterations) to use when selecting NSEC3 RRs.
2732 Hash collisions occur when different messages have the same hash
2733 value. The expected number of domain names needed to give a 1 in 2
2734 chance of a single collision is about 2^(n/2) for a hash of length n
2735 bits (i.e., 2^80 for SHA-1). Though this probability is extremely
2736 low, the following paragraphs deal with avoiding collisions and
2737 assessing possible damage in the event of an attack using hash
2746Laurie, et al. Standards Track [Page 49]
2748RFC 5155 NSEC3 March 2008
2751C.2.1. Avoiding Hash Collisions During Generation
2753 During generation of NSEC3 RRs, hash values are supposedly unique.
2754 In the (academic) case of a collision occurring, an alternative salt
2755 MUST be chosen and all hash values MUST be regenerated.
2757C.2.2. Second Preimage Requirement Analysis
2759 A cryptographic hash function has a second-preimage resistance
2760 property. The second-preimage resistance property means that it is
2761 computationally infeasible to find another message with the same hash
2762 value as a given message, i.e., given preimage X, to find a second
2763 preimage X' != X such that hash(X) = hash(X'). The work factor for
2764 finding a second preimage is of the order of 2^160 for SHA-1. To
2765 mount an attack using an existing NSEC3 RR, an adversary needs to
2766 find a second preimage.
2768 Assuming an adversary is capable of mounting such an extreme attack,
2769 the actual damage is that a response message can be generated that
2770 claims that a certain QNAME (i.e., the second pre-image) does exist,
2771 while in reality QNAME does not exist (a false positive), which will
2772 either cause a security-aware resolver to re-query for the non-
2773 existent name, or to fail the initial query. Note that the adversary
2774 can't mount this attack on an existing name, but only on a name that
2775 the adversary can't choose and that does not yet exist.
2802Laurie, et al. Standards Track [Page 50]
2804RFC 5155 NSEC3 March 2008
2815 Phone: +44 20 8735 0686
2816 EMail: ben@links.org
2827 Phone: +44 1865 332211
2828 EMail: geoff-s@panix.com
2839 Phone: +44 1865 332211
2840 EMail: roy@nominet.org.uk
2845 21355 Ridgetop Circle
2849 Phone: +1 703 948 3200
2850 EMail: davidb@verisign.com
2858Laurie, et al. Standards Track [Page 51]
2860RFC 5155 NSEC3 March 2008
2863Full Copyright Statement
2865 Copyright (C) The IETF Trust (2008).
2867 This document is subject to the rights, licenses and restrictions
2868 contained in BCP 78, and except as set forth therein, the authors
2869 retain all their rights.
2871 This document and the information contained herein are provided on an
2872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2874 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2875 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2876 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2879Intellectual Property
2881 The IETF takes no position regarding the validity or scope of any
2882 Intellectual Property Rights or other rights that might be claimed to
2883 pertain to the implementation or use of the technology described in
2884 this document or the extent to which any license under such rights
2885 might or might not be available; nor does it represent that it has
2886 made any independent effort to identify any such rights. Information
2887 on the procedures with respect to rights in RFC documents can be
2888 found in BCP 78 and BCP 79.
2890 Copies of IPR disclosures made to the IETF Secretariat and any
2891 assurances of licenses to be made available, or the result of an
2892 attempt made to obtain a general license or permission for the use of
2893 such proprietary rights by implementers or users of this
2894 specification can be obtained from the IETF on-line IPR repository at
2895 http://www.ietf.org/ipr.
2897 The IETF invites any interested party to bring to its attention any
2898 copyrights, patents or patent applications, or other proprietary
2899 rights that may cover technology that may be required to implement
2900 this standard. Please address the information to the IETF at
2914Laurie, et al. Standards Track [Page 52]