1 Network Working Group B. Laurie
2 Request for Comments: 5155 G. Sisson
3 Category: Standards Track R. Arends
4 Nominet
5 D. Blacka
6 VeriSign, Inc.
7 March 2008
8
9
10 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
11
12 Status of This Memo
13
14 This document specifies an Internet standards track protocol for the
15 Internet community, and requests discussion and suggestions for
16 improvements. Please refer to the current edition of the "Internet
17 Official Protocol Standards" (STD 1) for the standardization state
18 and status of this protocol. Distribution of this memo is unlimited.
19
20 Abstract
21
22 The Domain Name System Security (DNSSEC) Extensions introduced the
23 NSEC resource record (RR) for authenticated denial of existence.
24 This document introduces an alternative resource record, NSEC3, which
25 similarly provides authenticated denial of existence. However, it
26 also provides measures against zone enumeration and permits gradual
27 expansion of delegation-centric zones.
28
29 Table of Contents
30
31 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
32 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
33 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
34 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
35 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
36 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 7
37 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8
38 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8
39 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8
40 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8
41 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 8
42 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 8
43 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9
44 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9
45 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9
46 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
47 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
48 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 11
49
50
51
52 Laurie, et al. Standards Track [Page 1]
53 RFC 5155 NSEC3 March 2008
54
55
56 4. The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
57 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
58 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
59 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 12
60 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13
61 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13
62 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
63 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
64 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 14
65 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 14
66 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
67 7. Authoritative Server Considerations . . . . . . . . . . . . . 16
68 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
69 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
70 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18
71 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 19
72 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19
73 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
74 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 19
75 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 20
76 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20
77 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20
78 7.2.9. Server Response to a Run-Time Collision . . . . . . . 21
79 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 21
80 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21
81 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
82 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 23
83 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 23
84 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 23
85 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
86 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24
87 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24
88 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24
89 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 25
90 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 25
91 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25
92 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 26
93 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 26
94 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 26
95 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
96 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26
97 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
98 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
99 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
100 10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
102 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
103 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
104
105
106
107 Laurie, et al. Standards Track [Page 2]
108 RFC 5155 NSEC3 March 2008
109
110
111 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
112 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
113 12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 31
114 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31
115 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
116 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
117 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
118 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
119 13.2. Informative References . . . . . . . . . . . . . . . . . . 34
120 Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 35
121 Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 40
122 B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
123 B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 42
124 B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 43
125 B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
126 B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
127 B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
128 B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 48
129 Appendix C. Special Considerations . . . . . . . . . . . . . . . 48
130 C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 49
131 C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
132 C.2.1. Avoiding Hash Collisions During Generation . . . . . . 50
133 C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 50
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162 Laurie, et al. Standards Track [Page 3]
163 RFC 5155 NSEC3 March 2008
164
165
166 1. Introduction
167
168 1.1. Rationale
169
170 The DNS Security Extensions included the NSEC RR to provide
171 authenticated denial of existence. Though the NSEC RR meets the
172 requirements for authenticated denial of existence, it introduces a
173 side-effect in that the contents of a zone can be enumerated. This
174 property introduces undesired policy issues.
175
176 The enumeration is enabled by the set of NSEC records that exists
177 inside a signed zone. An NSEC record lists two names that are
178 ordered canonically, in order to show that nothing exists between the
179 two names. The complete set of NSEC records lists all the names in a
180 zone. It is trivial to enumerate the content of a zone by querying
181 for names that do not exist.
182
183 An enumerated zone can be used, for example, as a source of probable
184 e-mail addresses for spam, or as a key for multiple WHOIS queries to
185 reveal registrant data that many registries may have legal
186 obligations to protect. Many registries therefore prohibit the
187 copying of their zone data; however, the use of NSEC RRs renders
188 these policies unenforceable.
189
190 A second problem is that the cost to cryptographically secure
191 delegations to unsigned zones is high, relative to the perceived
192 security benefit, in two cases: large, delegation-centric zones, and
193 zones where insecure delegations will be updated rapidly. In these
194 cases, the costs of maintaining the NSEC RR chain may be extremely
195 high and use of the "Opt-Out" convention may be more appropriate (for
196 these unsecured zones).
197
198 This document presents the NSEC3 Resource Record which can be used as
199 an alternative to NSEC to mitigate these issues.
200
201 Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
202 and [DNSEXT-NSEC2v2].
203
204 1.2. Requirements
205
206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
208 document are to be interpreted as described in [RFC2119].
209
210
211
212
213
214
215
216
217 Laurie, et al. Standards Track [Page 4]
218 RFC 5155 NSEC3 March 2008
219
220
221 1.3. Terminology
222
223 The reader is assumed to be familiar with the basic DNS and DNSSEC
224 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
225 [RFC4035], and subsequent RFCs that update them: [RFC2136],
226 [RFC2181], and [RFC2308].
227
228 The following terminology is used throughout this document:
229
230 Zone enumeration: the practice of discovering the full content of a
231 zone via successive queries. Zone enumeration was non-trivial
232 prior to the introduction of DNSSEC.
233
234 Original owner name: the owner name corresponding to a hashed owner
235 name.
236
237 Hashed owner name: the owner name created after applying the hash
238 function to an owner name.
239
240 Hash order: the order in which hashed owner names are arranged
241 according to their numerical value, treating the leftmost (lowest
242 numbered) octet as the most significant octet. Note that this
243 order is the same as the canonical DNS name order specified in
244 [RFC4034], when the hashed owner names are in base32, encoded with
245 an Extended Hex Alphabet [RFC4648].
246
247 Empty non-terminal: a domain name that owns no resource records, but
248 has one or more subdomains that do.
249
250 Delegation: an NS RRSet with a name different from the current zone
251 apex (non-zone-apex), signifying a delegation to a child zone.
252
253 Secure delegation: a name containing a delegation (NS RRSet) and a
254 signed DS RRSet, signifying a delegation to a signed child zone.
255
256 Insecure delegation: a name containing a delegation (NS RRSet), but
257 lacking a DS RRSet, signifying a delegation to an unsigned child
258 zone.
259
260 Opt-Out NSEC3 resource record: an NSEC3 resource record that has the
261 Opt-Out flag set to 1.
262
263 Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR.
264
265 Closest encloser: the longest existing ancestor of a name. See also
266 Section 3.3.1 of [RFC4592].
267
268
269
270
271
272 Laurie, et al. Standards Track [Page 5]
273 RFC 5155 NSEC3 March 2008
274
275
276 Closest provable encloser: the longest ancestor of a name that can
277 be proven to exist. Note that this is only different from the
278 closest encloser in an Opt-Out zone.
279
280 Next closer name: the name one label longer than the closest
281 provable encloser of a name.
282
283 Base32: the "Base 32 Encoding with Extended Hex Alphabet" as
284 specified in [RFC4648]. Note that trailing padding characters
285 ("=") are not used in the NSEC3 specification.
286
287 To cover: An NSEC3 RR is said to "cover" a name if the hash of the
288 name or "next closer" name falls between the owner name and the
289 next hashed owner name of the NSEC3. In other words, if it proves
290 the nonexistence of the name, either directly or by proving the
291 nonexistence of an ancestor of the name.
292
293 To match: An NSEC3 RR is said to "match" a name if the owner name of
294 the NSEC3 RR is the same as the hashed owner name of that name.
295
296 2. Backwards Compatibility
297
298 This specification describes a protocol change that is not generally
299 backwards compatible with [RFC4033], [RFC4034], and [RFC4035]. In
300 particular, security-aware resolvers that are unaware of this
301 specification (NSEC3-unaware resolvers) may fail to validate the
302 responses introduced by this document.
303
304 In order to aid deployment, this specification uses a signaling
305 technique to prevent NSEC3-unaware resolvers from attempting to
306 validate responses from NSEC3-signed zones.
307
308 This specification allocates two new DNSKEY algorithm identifiers for
309 this purpose. Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
310 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
311 RSASHA1. These are not new algorithms, they are additional
312 identifiers for the existing algorithms.
313
314 Zones signed according to this specification MUST only use these
315 algorithm identifiers for their DNSKEY RRs. Because these new
316 identifiers will be unknown algorithms to existing, NSEC3-unaware
317 resolvers, those resolvers will then treat responses from the NSEC3
318 signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
319
320 These algorithm identifiers are used with the NSEC3 hash algorithm
321 SHA1. Using other NSEC3 hash algorithms requires allocation of a new
322 alias (see Section 12.1.3).
323
324
325
326
327 Laurie, et al. Standards Track [Page 6]
328 RFC 5155 NSEC3 March 2008
329
330
331 Security aware resolvers that are aware of this specification MUST
332 recognize the new algorithm identifiers and treat them as equivalent
333 to the algorithms that they alias.
334
335 A methodology for transitioning from a DNSSEC signed zone to a zone
336 signed using NSEC3 is discussed in Section 10.4.
337
338 3. The NSEC3 Resource Record
339
340 The NSEC3 Resource Record (RR) provides authenticated denial of
341 existence for DNS Resource Record Sets.
342
343 The NSEC3 RR lists RR types present at the original owner name of the
344 NSEC3 RR. It includes the next hashed owner name in the hash order
345 of the zone. The complete set of NSEC3 RRs in a zone indicates which
346 RRSets exist for the original owner name of the RR and form a chain
347 of hashed owner names in the zone. This information is used to
348 provide authenticated denial of existence for DNS data. To provide
349 protection against zone enumeration, the owner names used in the
350 NSEC3 RR are cryptographic hashes of the original owner name
351 prepended as a single label to the name of the zone. The NSEC3 RR
352 indicates which hash function is used to construct the hash, which
353 salt is used, and how many iterations of the hash function are
354 performed over the original owner name. The hashing technique is
355 described fully in Section 5.
356
357 Hashed owner names of unsigned delegations may be excluded from the
358 chain. An NSEC3 RR whose span covers the hash of an owner name or
359 "next closer" name of an unsigned delegation is referred to as an
360 Opt-Out NSEC3 RR and is indicated by the presence of a flag.
361
362 The owner name for the NSEC3 RR is the base32 encoding of the hashed
363 owner name prepended as a single label to the name of the zone.
364
365 The type value for the NSEC3 RR is 50.
366
367 The NSEC3 RR RDATA format is class independent and is described
368 below.
369
370 The class MUST be the same as the class of the original owner name.
371
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
Section 2.1 of RFC6840 says that "Validator implementations are strongly encouraged to include support for NSEC3 because a number of highly visible zones use it." In addition, it states that RFC 5155 "is now considered part of the DNS Security Document Family".
Section 2.2 of RFC 6944 says that the status of NSEC3 is Recommended to Implement. Note that RFC 6944 is obsoleted by RFC8624, which keeps the same recommendation to implement.
RFC9077 has significant updates to the way that TTL values are calculated. See two updates below.
372 The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
373 field. This is in the spirit of negative caching [RFC2308].
374
375
376
377
378
379
380
381
382 Laurie, et al. Standards Track [Page 7]
383 RFC 5155 NSEC3 March 2008
384
385
386 3.1. RDATA Fields
387
388 3.1.1. Hash Algorithm
389
390 The Hash Algorithm field identifies the cryptographic hash algorithm
391 used to construct the hash-value.
392
393 The values for this field are defined in the NSEC3 hash algorithm
394 registry defined in Section 11.
395
396 3.1.2. Flags
397
398 The Flags field contains 8 one-bit flags that can be used to indicate
399 different processing. All undefined flags must be zero. The only
400 flag defined by this specification is the Opt-Out flag.
401
402 3.1.2.1. Opt-Out Flag
403
404 If the Opt-Out flag is set, the NSEC3 record covers zero or more
405 unsigned delegations.
406
407 If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
408 delegations.
409
410 The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
411 delegations. It is the least significant bit in the Flags field.
412 See Section 6 for details about the use of this flag.
413
414 3.1.3. Iterations
415
416 The Iterations field defines the number of additional times the hash
417 function has been performed. More iterations result in greater
418 resiliency of the hash value against dictionary attacks, but at a
419 higher computational cost for both the server and resolver. See
420 Section 5 for details of the use of this field, and Section 10.3 for
421 limitations on the value.
422
423 3.1.4. Salt Length
424
425 The Salt Length field defines the length of the Salt field in octets,
426 ranging in value from 0 to 255.
427
428 3.1.5. Salt
429
430 The Salt field is appended to the original owner name before hashing
431 in order to defend against pre-calculated dictionary attacks. See
432 Section 5 for details on how the salt is used.
433
434
435
436
437 Laurie, et al. Standards Track [Page 8]
438 RFC 5155 NSEC3 March 2008
439
440
441 3.1.6. Hash Length
442
443 The Hash Length field defines the length of the Next Hashed Owner
444 Name field, ranging in value from 1 to 255 octets.
445
446 3.1.7. Next Hashed Owner Name
447
448 The Next Hashed Owner Name field contains the next hashed owner name
449 in hash order. This value is in binary format. Given the ordered
450 set of all hashed owner names, the Next Hashed Owner Name field
451 contains the hash of an owner name that immediately follows the owner
452 name of the given NSEC3 RR. The value of the Next Hashed Owner Name
453 field in the last NSEC3 RR in the zone is the same as the hashed
454 owner name of the first NSEC3 RR in the zone in hash order. Note
455 that, unlike the owner name of the NSEC3 RR, the value of this field
456 does not contain the appended zone name.
457
458 3.1.8. Type Bit Maps
459
460 The Type Bit Maps field identifies the RRSet types that exist at the
461 original owner name of the NSEC3 RR.
462
463 3.2. NSEC3 RDATA Wire Format
464
465 The RDATA of the NSEC3 RR is as shown below:
466
467 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
468 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
469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
470 | Hash Alg. | Flags | Iterations |
471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
472 | Salt Length | Salt /
473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
474 | Hash Length | Next Hashed Owner Name /
475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
476 / Type Bit Maps /
477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
478
479 Hash Algorithm is a single octet.
480
481 Flags field is a single octet, the Opt-Out flag is the least
482 significant bit, as shown below:
483
484 0 1 2 3 4 5 6 7
485 +-+-+-+-+-+-+-+-+
486 | |O|
487 +-+-+-+-+-+-+-+-+
488
489
490
491
492 Laurie, et al. Standards Track [Page 9]
493 RFC 5155 NSEC3 March 2008
494
495
496 Iterations is represented as a 16-bit unsigned integer, with the most
497 significant bit first.
498
499 Salt Length is represented as an unsigned octet. Salt Length
500 represents the length of the Salt field in octets. If the value is
501 zero, the following Salt field is omitted.
502
503 Salt, if present, is encoded as a sequence of binary octets. The
504 length of this field is determined by the preceding Salt Length
505 field.
506
507 Hash Length is represented as an unsigned octet. Hash Length
508 represents the length of the Next Hashed Owner Name field in octets.
509
510 The next hashed owner name is not base32 encoded, unlike the owner
511 name of the NSEC3 RR. It is the unmodified binary hash value. It
512 does not include the name of the containing zone. The length of this
513 field is determined by the preceding Hash Length field.
514
515 3.2.1. Type Bit Maps Encoding
516
517 The encoding of the Type Bit Maps field is the same as that used by
518 the NSEC RR, described in [RFC4034]. It is explained and clarified
519 here for clarity.
520
521 The RR type space is split into 256 window blocks, each representing
522 the low-order 8 bits of the 16-bit RR type space. Each block that
523 has at least one active RR type is encoded using a single octet
524 window number (from 0 to 255), a single octet bitmap length (from 1
525 to 32) indicating the number of octets used for the bitmap of the
526 window block, and up to 32 octets (256 bits) of bitmap.
527
528 Blocks are present in the NSEC3 RR RDATA in increasing numerical
529 order.
530
531 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
532
533 where "|" denotes concatenation.
534
535 Each bitmap encodes the low-order 8 bits of RR types within the
536 window block, in network bit order. The first bit is bit 0. For
537 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
538 to RR type 2 (NS), and so forth. For window block 1, bit 1
539 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
540 1, it indicates that an RRSet of that type is present for the
541 original owner name of the NSEC3 RR. If a bit is set to 0, it
542 indicates that no RRSet of that type is present for the original
543 owner name of the NSEC3 RR.
544
545
546
547 Laurie, et al. Standards Track [Page 10]
548 RFC 5155 NSEC3 March 2008
549
550
551 Since bit 0 in window block 0 refers to the non-existing RR type 0,
552 it MUST be set to 0. After verification, the validator MUST ignore
553 the value of bit 0 in window block 0.
554
555 Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
556 [RFC2929] or within the range reserved for assignment only to QTYPEs
557 and Meta-TYPEs MUST be set to 0, since they do not appear in zone
558 data. If encountered, they must be ignored upon reading.
559
560 Blocks with no types present MUST NOT be included. Trailing zero
561 octets in the bitmap MUST be omitted. The length of the bitmap of
562 each block is determined by the type code with the largest numerical
563 value, within that block, among the set of RR types present at the
564 original owner name of the NSEC3 RR. Trailing octets not specified
565 MUST be interpreted as zero octets.
566
567 3.3. Presentation Format
568
569 The presentation format of the RDATA portion is as follows:
570
571 o The Hash Algorithm field is represented as an unsigned decimal
572 integer. The value has a maximum of 255.
573
574 o The Flags field is represented as an unsigned decimal integer.
575 The value has a maximum of 255.
576
577 o The Iterations field is represented as an unsigned decimal
578 integer. The value is between 0 and 65535, inclusive.
579
580 o The Salt Length field is not represented.
581
582 o The Salt field is represented as a sequence of case-insensitive
583 hexadecimal digits. Whitespace is not allowed within the
584 sequence. The Salt field is represented as "-" (without the
585 quotes) when the Salt Length field has a value of 0.
586
587 o The Hash Length field is not represented.
588
RFC9077 changes "The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching [RFC2308]." to:
The TTL of the NSEC3 RR that is returned MUST be the lesser of the MINIMUM field of the SOA record and the TTL of the SOA itself. This matches the definition of the TTL for negative responses in [RFC2308]. Because some signers incrementally update the NSEC3 chain, a transient inconsistency between the observed and expected TTL MAY exist.
589 o The Next Hashed Owner Name field is represented as an unpadded
590 sequence of case-insensitive base32 digits, without whitespace.
591
592 o The Type Bit Maps field is represented as a sequence of RR type
593 mnemonics. When the mnemonic is not known, the TYPE
594 representation as described in Section 5 of [RFC3597] MUST be
595 used.
596
597
598
599
600
601
602 Laurie, et al. Standards Track [Page 11]
603 RFC 5155 NSEC3 March 2008
604
605
606 4. The NSEC3PARAM Resource Record
607
608 The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
609 flags, iterations, and salt) needed by authoritative servers to
610 calculate hashed owner names. The presence of an NSEC3PARAM RR at a
611 zone apex indicates that the specified parameters may be used by
612 authoritative servers to choose an appropriate set of NSEC3 RRs for
613 negative responses. The NSEC3PARAM RR is not used by validators or
614 resolvers.
615
616 If an NSEC3PARAM RR is present at the apex of a zone with a Flags
617 field value of zero, then there MUST be an NSEC3 RR using the same
618 hash algorithm, iterations, and salt parameters present at every
619 hashed owner name in the zone. That is, the zone MUST contain a
620 complete set of NSEC3 RRs with the same hash algorithm, iterations,
621 and salt parameters.
622
623 The owner name for the NSEC3PARAM RR is the name of the zone apex.
624
625 The type value for the NSEC3PARAM RR is 51.
626
627 The NSEC3PARAM RR RDATA format is class independent and is described
628 below.
629
630 The class MUST be the same as the NSEC3 RRs to which this RR refers.
631
632 4.1. RDATA Fields
633
634 The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
635
636 4.1.1. Hash Algorithm
637
638 The Hash Algorithm field identifies the cryptographic hash algorithm
639 used to construct the hash-value.
640
641 The acceptable values are the same as the corresponding field in the
642 NSEC3 RR.
643
644 4.1.2. Flag Fields
645
646 The Opt-Out flag is not used and is set to zero.
647
648 All other flags are reserved for future use, and must be zero.
649
650 NSEC3PARAM RRs with a Flags field value other than zero MUST be
651 ignored.
652
653
654
655
656
657 Laurie, et al. Standards Track [Page 12]
658 RFC 5155 NSEC3 March 2008
659
660
661 4.1.3. Iterations
662
663 The Iterations field defines the number of additional times the hash
664 is performed.
665
666 Its acceptable values are the same as the corresponding field in the
667 NSEC3 RR.
668
669 4.1.4. Salt Length
670
671 The Salt Length field defines the length of the salt in octets,
672 ranging in value from 0 to 255.
673
674 4.1.5. Salt
675
676 The Salt field is appended to the original owner name before hashing.
677
678 4.2. NSEC3PARAM RDATA Wire Format
679
680 The RDATA of the NSEC3PARAM RR is as shown below:
681
682 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
683 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
684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
685 | Hash Alg. | Flags | Iterations |
686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
687 | Salt Length | Salt /
688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
689
690 Hash Algorithm is a single octet.
691
692 Flags field is a single octet.
693
694 Iterations is represented as a 16-bit unsigned integer, with the most
695 significant bit first.
696
697 Salt Length is represented as an unsigned octet. Salt Length
698 represents the length of the following Salt field in octets. If the
699 value is zero, the Salt field is omitted.
700
701 Salt, if present, is encoded as a sequence of binary octets. The
702 length of this field is determined by the preceding Salt Length
703 field.
704
705
706
707
708
709
710
711
712 Laurie, et al. Standards Track [Page 13]
713 RFC 5155 NSEC3 March 2008
714
715
716 4.3. Presentation Format
717
718 The presentation format of the RDATA portion is as follows:
719
720 o The Hash Algorithm field is represented as an unsigned decimal
721 integer. The value has a maximum of 255.
722
723 o The Flags field is represented as an unsigned decimal integer.
724 The value has a maximum value of 255.
725
726 o The Iterations field is represented as an unsigned decimal
727 integer. The value is between 0 and 65535, inclusive.
728
729 o The Salt Length field is not represented.
730
731 o The Salt field is represented as a sequence of case-insensitive
732 hexadecimal digits. Whitespace is not allowed within the
733 sequence. This field is represented as "-" (without the quotes)
734 when the Salt Length field is zero.
735
736 5. Calculation of the Hash
737
738 The hash calculation uses three of the NSEC3 RDATA fields: Hash
739 Algorithm, Salt, and Iterations.
740
741 Define H(x) to be the hash of x using the Hash Algorithm selected by
742 the NSEC3 RR, k to be the number of Iterations, and || to indicate
743 concatenation. Then define:
744
745 IH(salt, x, 0) = H(x || salt), and
746
747 IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
748
749 Then the calculated hash of an owner name is
750
751 IH(salt, owner name, iterations),
752
753 where the owner name is in the canonical form, defined as:
754
755 The wire format of the owner name where:
756
757 1. The owner name is fully expanded (no DNS name compression) and
758 fully qualified;
759
760 2. All uppercase US-ASCII letters are replaced by the corresponding
761 lowercase US-ASCII letters;
762
763
764
765
766
767 Laurie, et al. Standards Track [Page 14]
768 RFC 5155 NSEC3 March 2008
769
770
771 3. If the owner name is a wildcard name, the owner name is in its
772 original unexpanded form, including the "*" label (no wildcard
773 substitution);
774
775 This form is as defined in Section 6.2 of [RFC4034].
776
777 The method to calculate the Hash is based on [RFC2898].
778
779 6. Opt-Out
780
781 In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
782 RRSets at delegation points are not signed and may be accompanied by
783 a DS RRSet. With the Opt-Out bit clear, the security status of the
784 child zone is determined by the presence or absence of this DS RRSet,
785 cryptographically proven by the signed NSEC3 RR at the hashed owner
786 name of the delegation. Setting the Opt-Out flag modifies this by
787 allowing insecure delegations to exist within the signed zone without
788 a corresponding NSEC3 RR at the hashed owner name of the delegation.
789
790 An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
791 owner name or "next closer" name of the delegation is between the
792 owner name of the NSEC3 RR and the next hashed owner name.
793
794 An Opt-Out NSEC3 RR does not assert the existence or non-existence of
795 the insecure delegations that it may cover. This allows for the
796 addition or removal of these delegations without recalculating or re-
797 signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do
798 assert the (non)existence of other, authoritative RRSets.
799
800 An Opt-Out NSEC3 RR MAY have the same original owner name as an
801 insecure delegation. In this case, the delegation is proven insecure
802 by the lack of a DS bit in the type map and the signed NSEC3 RR does
803 assert the existence of the delegation.
804
805 Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
806 non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT
807 be any hashed owner names of insecure delegations (nor any other RRs)
808 between it and the name indicated by the next hashed owner name in
809 the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner
810 names or hashed "next closer" names of insecure delegations.
811
812 The effects of the Opt-Out flag on signing, serving, and validating
813 responses are covered in following sections.
814
815
816
817
818
819
820
821
822 Laurie, et al. Standards Track [Page 15]
823 RFC 5155 NSEC3 March 2008
824
825
826 7. Authoritative Server Considerations
827
828 7.1. Zone Signing
829
830 Zones using NSEC3 must satisfy the following properties:
831
832 o Each owner name within the zone that owns authoritative RRSets
833 MUST have a corresponding NSEC3 RR. Owner names that correspond
834 to unsigned delegations MAY have a corresponding NSEC3 RR.
835 However, if there is not a corresponding NSEC3 RR, there MUST be
836 an Opt-Out NSEC3 RR that covers the "next closer" name to the
837 delegation. Other non-authoritative RRs are not represented by
838 NSEC3 RRs.
839
840 o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
841 the empty non-terminal is only derived from an insecure delegation
842 covered by an Opt-Out NSEC3 RR.
843
o The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32 digits, without whitespace.
o The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32hex digits, without whitespace.
844 o The TTL value for any NSEC3 RR SHOULD be the same as the minimum
845 TTL value field in the zone SOA RR.
846
847 o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
848 indicate the presence of all types present at the original owner
849 name, except for the types solely contributed by an NSEC3 RR
850 itself. Note that this means that the NSEC3 type itself will
851 never be present in the Type Bit Maps.
852
853 The following steps describe a method of proper construction of NSEC3
854 RRs. This is not the only such possible method.
855
856 1. Select the hash algorithm and the values for salt and iterations.
857
858 2. For each unique original owner name in the zone add an NSEC3 RR.
859
860 * If Opt-Out is being used, owner names of unsigned delegations
861 MAY be excluded.
862
863 * The owner name of the NSEC3 RR is the hash of the original
864 owner name, prepended as a single label to the zone name.
865
866 * The Next Hashed Owner Name field is left blank for the moment.
867
868 * If Opt-Out is being used, set the Opt-Out bit to one.
869
870 * For collision detection purposes, optionally keep track of the
871 original owner name with the NSEC3 RR.
872
873
874
875
876
877 Laurie, et al. Standards Track [Page 16]
878 RFC 5155 NSEC3 March 2008
879
880
881 * Additionally, for collision detection purposes, optionally
882 create an additional NSEC3 RR corresponding to the original
883 owner name with the asterisk label prepended (i.e., as if a
884 wildcard existed as a child of this owner name) and keep track
885 of this original owner name. Mark this NSEC3 RR as temporary.
886
887 3. For each RRSet at the original owner name, set the corresponding
888 bit in the Type Bit Maps field.
889
890 4. If the difference in number of labels between the apex and the
891 original owner name is greater than 1, additional NSEC3 RRs need
892 to be added for every empty non-terminal between the apex and the
893 original owner name. This process may generate NSEC3 RRs with
894 duplicate hashed owner names. Optionally, for collision
895 detection, track the original owner names of these NSEC3 RRs and
896 create temporary NSEC3 RRs for wildcard collisions in a similar
897 fashion to step 1.
898
899 5. Sort the set of NSEC3 RRs into hash order.
900
901 6. Combine NSEC3 RRs with identical hashed owner names by replacing
902 them with a single NSEC3 RR with the Type Bit Maps field
903 consisting of the union of the types represented by the set of
904 NSEC3 RRs. If the original owner name was tracked, then
905 collisions may be detected when combining, as all of the matching
906 NSEC3 RRs should have the same original owner name. Discard any
907 possible temporary NSEC3 RRs.
908
909 7. In each NSEC3 RR, insert the next hashed owner name by using the
910 value of the next NSEC3 RR in hash order. The next hashed owner
911 name of the last NSEC3 RR in the zone contains the value of the
912 hashed owner name of the first NSEC3 RR in the hash order.
913
914 8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
915 Iterations, and Salt fields to the zone apex.
916
917 If a hash collision is detected, then a new salt has to be chosen,
918 and the signing process restarted.
919
920 7.2. Zone Serving
921
922 This specification modifies DNSSEC-enabled DNS responses generated by
923 authoritative servers. In particular, it replaces the use of NSEC
924 RRs in such responses with NSEC3 RRs.
925
926
927
928
929
930
931
932 Laurie, et al. Standards Track [Page 17]
933 RFC 5155 NSEC3 March 2008
934
935
936 In the following response cases, the NSEC RRs dictated by DNSSEC
937 [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
938 Responses that would not contain NSEC RRs are unchanged by this
939 specification.
940
941 When returning responses containing multiple NSEC3 RRs, all of the
942 NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
943 values. The Flags field value MUST be either zero or one.
944
945 7.2.1. Closest Encloser Proof
946
947 For many NSEC3 responses a proof of the closest encloser is required.
948 This is a proof that some ancestor of the QNAME is the closest
949 encloser of QNAME.
950
951 This proof consists of (up to) two different NSEC3 RRs:
952
953 o An NSEC3 RR that matches the closest (provable) encloser.
954
955 o An NSEC3 RR that covers the "next closer" name to the closest
956 encloser.
957
958 The first NSEC3 RR essentially proposes a possible closest encloser,
959 and proves that the particular encloser does, in fact, exist. The
960 second NSEC3 RR proves that the possible closest encloser is the
961 closest, and proves that the QNAME (and any ancestors between QNAME
962 and the closest encloser) does not exist.
963
964 These NSEC3 RRs are collectively referred to as the "closest encloser
965 proof" in the subsequent descriptions.
966
967 For example, the closest encloser proof for the nonexistent
968 "alpha.beta.gamma.example." owner name might prove that
969 "gamma.example." is the closest encloser. This response would
970 contain the NSEC3 RR that matches "gamma.example.", and would also
971 contain the NSEC3 RR that covers "beta.gamma.example." (which is the
972 "next closer" name).
973
974 It is possible, when using Opt-Out (Section 6), to not be able to
975 prove the actual closest encloser because it is, or is part of an
976 insecure delegation covered by an Opt-Out span. In this case,
977 instead of proving the actual closest encloser, the closest provable
978 encloser is used. That is, the closest enclosing authoritative name
979 is used instead. In this case, the set of NSEC3 RRs used for this
980 proof is referred to as the "closest provable encloser proof".
981
982
983
984
985
986
987 Laurie, et al. Standards Track [Page 18]
988 RFC 5155 NSEC3 March 2008
989
990
991 7.2.2. Name Error Responses
992
993 To prove the nonexistence of QNAME, a closest encloser proof and an
994 NSEC3 RR covering the (nonexistent) wildcard RR at the closest
995 encloser MUST be included in the response. This collection of (up
996 to) three NSEC3 RRs proves both that QNAME does not exist and that a
997 wildcard that could have matched QNAME also does not exist.
998
999 For example, if "gamma.example." is the closest provable encloser to
1000 QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
1001 the authority section of the response.
1002
RFC9077 changes "The TTL value for any NSEC3 RR SHOULD be the same as the
minimum TTL value field in the zone SOA RR." to:
* The TTL value for each NSEC3 RR MUST be the lesser of the MINIMUM field of the zone SOA RR and the TTL of the zone SOA RR itself. Because some signers incrementally update the NSEC3 chain, a transient inconsistency between the observed and expected TTL MAY exist.
1003 7.2.3. No Data Responses, QTYPE is not DS
1004
1005 The server MUST include the NSEC3 RR that matches QNAME. This NSEC3
1006 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
1007 set in its Type Bit Maps field.
1008
1009 7.2.4. No Data Responses, QTYPE is DS
1010
1011 If there is an NSEC3 RR that matches QNAME, the server MUST return it
1012 in the response. The bits corresponding with DS and CNAME MUST NOT
1013 be set in the Type Bit Maps field of this NSEC3 RR.
1014
1015 If no NSEC3 RR matches QNAME, the server MUST return a closest
1016 provable encloser proof for QNAME. The NSEC3 RR that covers the
1017 "next closer" name MUST have the Opt-Out bit set (note that this is
1018 true by definition -- if the Opt-Out bit is not set, something has
1019 gone wrong).
1020
1021 If a server is authoritative for both sides of a zone cut at QNAME,
1022 the server MUST return the proof from the parent side of the zone
1023 cut.
1024
1025 7.2.5. Wildcard No Data Responses
1026
1027 If there is a wildcard match for QNAME, but QTYPE is not present at
1028 that name, the response MUST include a closest encloser proof for
1029 QNAME and MUST include the NSEC3 RR that matches the wildcard. This
1030 combination proves both that QNAME itself does not exist and that a
1031 wildcard that matches QNAME does exist. Note that the closest
1032 encloser to QNAME MUST be the immediate ancestor of the wildcard RR
1033 (if this is not the case, then something has gone wrong).
1034
1035
1036
1037
1038
1039
1040
1041
1042 Laurie, et al. Standards Track [Page 19]
1043 RFC 5155 NSEC3 March 2008
1044
1045
1046 7.2.6. Wildcard Answer Responses
1047
1048 If there is a wildcard match for QNAME and QTYPE, then, in addition
1049 to the expanded wildcard RRSet returned in the answer section of the
1050 response, proof that the wildcard match was valid must be returned.
1051
1052 This proof is accomplished by proving that both QNAME does not exist
1053 and that the closest encloser of the QNAME and the immediate ancestor
1054 of the wildcard are the same (i.e., the correct wildcard matched).
1055
1056 To this end, the NSEC3 RR that covers the "next closer" name of the
1057 immediate ancestor of the wildcard MUST be returned. It is not
1058 necessary to return an NSEC3 RR that matches the closest encloser, as
1059 the existence of this closest encloser is proven by the presence of
1060 the expanded wildcard in the response.
1061
1062 7.2.7. Referrals to Unsigned Subzones
1063
1064 If there is an NSEC3 RR that matches the delegation name, then that
1065 NSEC3 RR MUST be included in the response. The DS bit in the type
1066 bit maps of the NSEC3 RR MUST NOT be set.
1067
1068 If the zone is Opt-Out, then there may not be an NSEC3 RR
1069 corresponding to the delegation. In this case, the closest provable
1070 encloser proof MUST be included in the response. The included NSEC3
1071 RR that covers the "next closer" name for the delegation MUST have
1072 the Opt-Out flag set to one. (Note that this will be the case unless
1073 something has gone wrong).
1074
7.2.3. No Data Responses, QTYPE is not DS If the No Data Response is a result of an empty non-terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. In all other cases, the server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field.
1075 7.2.8. Responding to Queries for NSEC3 Owner Names
1076
1077 The owner names of NSEC3 RRs are not represented in the NSEC3 RR
1078 chain like other owner names. As a result, each NSEC3 owner name is
1079 covered by another NSEC3 RR, effectively negating the existence of
1080 the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR
1081 can be proven by its RRSIG RRSet.
1082
1083 If the following conditions are all true:
1084
1085 o the QNAME equals the owner name of an existing NSEC3 RR, and
1086
1087 o no RR types exist at the QNAME, nor at any descendant of QNAME,
1088
1089 then the response MUST be constructed as a Name Error response
1090 (Section 7.2.2). Or, in other words, the authoritative name server
1091 will act as if the owner name of the NSEC3 RR did not exist.
1092
1093
1094
1095
1096
1097 Laurie, et al. Standards Track [Page 20]
1098 RFC 5155 NSEC3 March 2008
1099
1100
1101 Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
1102 query.
1103
1104 7.2.9. Server Response to a Run-Time Collision
1105
1106 If the hash of a non-existing QNAME collides with the owner name of
1107 an existing NSEC3 RR, then the server will be unable to return a
1108 response that proves that QNAME does not exist. In this case, the
1109 server MUST return a response with an RCODE of 2 (server failure).
1110
1111 Note that with the hash algorithm specified in this document, SHA-1,
1112 such collisions are highly unlikely.
1113
1114 7.3. Secondary Servers
1115
1116 Secondary servers (and perhaps other entities) need to reliably
1117 determine which NSEC3 parameters (i.e., hash, salt, and iterations)
1118 are present at every hashed owner name, in order to be able to choose
1119 an appropriate set of NSEC3 RRs for negative responses. This is
1120 indicated by an NSEC3PARAM RR present at the zone apex.
1121
1122 If there are multiple NSEC3PARAM RRs present, there are multiple
1123 valid NSEC3 chains present. The server must choose one of them, but
1124 may use any criteria to do so.
1125
1126 7.4. Zones Using Unknown Hash Algorithms
1127
1128 Zones that are signed according to this specification, but are using
1129 an unrecognized NSEC3 hash algorithm value, cannot be effectively
1130 served. Such zones SHOULD be rejected when loading. Servers SHOULD
1131 respond with RCODE=2 (server failure) responses when handling queries
1132 that would fall under such zones.
1133
1134 7.5. Dynamic Update
1135
1136 A zone signed using NSEC3 may accept dynamic updates [RFC2136].
1137 However, NSEC3 introduces some special considerations for dynamic
1138 updates.
1139
1140 Adding and removing names in a zone MUST account for the creation or
1141 removal of empty non-terminals.
1142
1143 o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
1144 corresponding to empty non-terminals created by that name MUST be
1145 removed. Note that more than one name may be asserting the
1146 existence of a particular empty non-terminal.
1147
1148
1149
1150
1151
1152 Laurie, et al. Standards Track [Page 21]
1153 RFC 5155 NSEC3 March 2008
1154
1155
1156 o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
1157 MUST also be added for any empty non-terminals that are created.
1158 That is, if there is not an existing NSEC3 RR matching an empty
1159 non-terminal, it must be created and added.
1160
1161 The presence of Opt-Out in a zone means that some additions or
1162 delegations of names will not require changes to the NSEC3 RRs in a
1163 zone.
1164
1165 o When removing a delegation RRSet, if that delegation does not have
1166 a matching NSEC3 RR, then it was opted out. In this case, nothing
1167 further needs to be done.
1168
1169 o When adding a delegation RRSet, if the "next closer" name of the
1170 delegation is covered by an existing Opt-Out NSEC3 RR, then the
1171 delegation MAY be added without modifying the NSEC3 RRs in the
1172 zone.
1173
1174 The presence of Opt-Out in a zone means that when adding or removing
1175 NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
1176 modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of
1177 basic rules to resolve the ambiguity.
1178
1179 The central concept to these rules is that the state of the Opt-Out
1180 flag of the covering NSEC3 RR is preserved.
1181
1182 o When removing an NSEC3 RR, the value of the Opt-Out flag for the
1183 previous NSEC3 RR (the one whose next hashed owner name is
1184 modified) should not be changed.
1185
1186 o When adding an NSEC3 RR, the value of the Opt-Out flag is set to
1187 the value of the Opt-Out flag of the NSEC3 RR that previously
1188 covered the owner name of the NSEC3 RR. That is, the now previous
1189 NSEC3 RR.
1190
1191 If the zone in question is consistent with its use of the Opt-Out
1192 flag (that is, all NSEC3 RRs in the zone have the same value for the
1193 flag) then these rules will retain that consistency. If the zone is
1194 not consistent in the use of the flag (i.e., a partially Opt-Out
1195 zone), then these rules will not retain the same pattern of use of
1196 the Opt-Out flag.
1197
1198 For zones that partially use the Opt-Out flag, if there is a logical
1199 pattern for that use, the pattern could be maintained by using a
1200 local policy on the server.
1201
1202
1203
1204
1205
1206
1207 Laurie, et al. Standards Track [Page 22]
1208 RFC 5155 NSEC3 March 2008
1209
1210
1211 8. Validator Considerations
1212
1213 8.1. Responses with Unknown Hash Types
1214
1215 A validator MUST ignore NSEC3 RRs with unknown hash types. The
1216 practical result of this is that responses containing only such NSEC3
1217 RRs will generally be considered bogus.
1218
1219 8.2. Verifying NSEC3 RRs
1220
1221 A validator MUST ignore NSEC3 RRs with a Flag fields value other than
1222 zero or one.
1223
1224 A validator MAY treat a response as bogus if the response contains
1225 NSEC3 RRs that contain different values for hash algorithm,
1226 iterations, or salt from each other for that zone.
1227
1228 8.3. Closest Encloser Proof
1229
1230 In order to verify a closest encloser proof, the validator MUST find
1231 the longest name, X, such that
1232
1233 o X is an ancestor of QNAME that is matched by an NSEC3 RR present
1234 in the response. This is a candidate for the closest encloser,
1235 and
1236
1237 o The name one label longer than X (but still an ancestor of -- or
1238 equal to -- QNAME) is covered by an NSEC3 RR present in the
1239 response.
1240
1241 One possible algorithm for verifying this proof is as follows:
1242
1243 1. Set SNAME=QNAME. Clear the flag.
1244
1245 2. Check whether SNAME exists:
1246
1247 * If there is no NSEC3 RR in the response that matches SNAME
1248 (i.e., an NSEC3 RR whose owner name is the same as the hash of
1249 SNAME, prepended as a single label to the zone name), clear
1250 the flag.
1251
1252 * If there is an NSEC3 RR in the response that covers SNAME, set
1253 the flag.
1254
1255 * If there is a matching NSEC3 RR in the response and the flag
1256 was set, then the proof is complete, and SNAME is the closest
1257 encloser.
1258
1259
1260
1261
1262 Laurie, et al. Standards Track [Page 23]
1263 RFC 5155 NSEC3 March 2008
1264
1265
1266 * If there is a matching NSEC3 RR in the response, but the flag
1267 is not set, then the response is bogus.
1268
1269 3. Truncate SNAME by one label from the left, go to step 2.
1270
1271 Once the closest encloser has been discovered, the validator MUST
1272 check that the NSEC3 RR that has the closest encloser as the original
1273 owner name is from the proper zone. The DNAME type bit must not be
1274 set and the NS type bit may only be set if the SOA type bit is set.
1275 If this is not the case, it would be an indication that an attacker
1276 is using them to falsely deny the existence of RRs for which the
1277 server is not authoritative.
1278
1279 In the following descriptions, the phrase "a closest (provable)
1280 encloser proof for X" means that the algorithm above (or an
1281 equivalent algorithm) proves that X does not exist by proving that an
1282 ancestor of X is its closest encloser.
1283
1284 8.4. Validating Name Error Responses
1285
1286 A validator MUST verify that there is a closest encloser proof for
1287 QNAME present in the response and that there is an NSEC3 RR that
1288 covers the wildcard at the closest encloser (i.e., the name formed by
1289 prepending the asterisk label to the closest encloser).
1290
7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist.
7.2.8. Responding to Queries for NSEC3 Owner Names
The owner names of NSEC3 RRs are not represented in the NSEC3 RR
chain like other owner names. As a result, each NSEC3 owner name is
covered by another NSEC3 RR, effectively negating the existence of
the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR
can be proven by its RRSIG RRSet.
If the following conditions are all true:
o the QNAME equals the owner name of an existing NSEC3 RR, and
o no RR types exist at the QNAME besides NSEC3, nor at any
descendant of QNAME,
then the response MUST be constructed as a Name Error response
(Section 7.2.2). Or, in other words, the authoritative name server
will act as if the owner name of the NSEC3 RR did not exist.
1291 8.5. Validating No Data Responses, QTYPE is not DS
1292
1293 The validator MUST verify that an NSEC3 RR that matches QNAME is
1294 present and that both the QTYPE and the CNAME type are not set in its
1295 Type Bit Maps field.
1296
1297 Note that this test also covers the case where the NSEC3 RR exists
1298 because it corresponds to an empty non-terminal, in which case the
1299 NSEC3 RR will have an empty Type Bit Maps field.
1300
1301 8.6. Validating No Data Responses, QTYPE is DS
1302
1303 If there is an NSEC3 RR that matches QNAME present in the response,
1304 then that NSEC3 RR MUST NOT have the bits corresponding to DS and
1305 CNAME set in its Type Bit Maps field.
1306
1307 If there is no such NSEC3 RR, then the validator MUST verify that a
1308 closest provable encloser proof for QNAME is present in the response,
1309 and that the NSEC3 RR that covers the "next closer" name has the Opt-
1310 Out bit set.
1311
1312
1313
1314
1315
1316
1317 Laurie, et al. Standards Track [Page 24]
1318 RFC 5155 NSEC3 March 2008
1319
1320
1321 8.7. Validating Wildcard No Data Responses
1322
1323 The validator MUST verify a closest encloser proof for QNAME and MUST
1324 find an NSEC3 RR present in the response that matches the wildcard
1325 name generated by prepending the asterisk label to the closest
1326 encloser. Furthermore, the bits corresponding to both QTYPE and
1327 CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
1328
1329 8.8. Validating Wildcard Answer Responses
1330
1331 The verified wildcard answer RRSet in the response provides the
1332 validator with a (candidate) closest encloser for QNAME. This
1333 closest encloser is the immediate ancestor to the generating
1334 wildcard.
1335
1336 Validators MUST verify that there is an NSEC3 RR that covers the
1337 "next closer" name to QNAME present in the response. This proves
1338 that QNAME itself did not exist and that the correct wildcard was
1339 used to generate the response.
1340
1341 8.9. Validating Referrals to Unsigned Subzones
1342
1343 The delegation name in a referral is the owner name of the NS RRSet
1344 present in the authority section of the referral response.
1345
1346 If there is an NSEC3 RR present in the response that matches the
1347 delegation name, then the validator MUST ensure that the NS bit is
1348 set and that the DS bit is not set in the Type Bit Maps field of the
1349 NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from
1350 the correct (i.e., parent) zone. This is done by ensuring that the
1351 SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
1352
1353 Note that the presence of an NS bit implies the absence of a DNAME
1354 bit, so there is no need to check for the DNAME bit in the Type Bit
1355 Maps field of the NSEC3 RR.
1356
1357 If there is no NSEC3 RR present that matches the delegation name,
1358 then the validator MUST verify a closest provable encloser proof for
1359 the delegation name. The validator MUST verify that the Opt-Out bit
1360 is set in the NSEC3 RR that covers the "next closer" name to the
1361 delegation name.
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372 Laurie, et al. Standards Track [Page 25]
1373 RFC 5155 NSEC3 March 2008
1374
1375
1376 9. Resolver Considerations
1377
1378 9.1. NSEC3 Resource Record Caching
1379
1380 Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
1381 when returning responses that contain them. In DNSSEC [RFC4035], in
1382 many cases it is possible to find the correct NSEC RR to return in a
1383 response by name (e.g., when returning a referral, the NSEC RR will
1384 always have the same owner name as the delegation). With this
1385 specification, that will not be true, nor will a cache be able to
1386 calculate the name(s) of the appropriate NSEC3 RR(s).
1387 Implementations may need to use new methods for caching and
1388 retrieving NSEC3 RRs.
1389
1390 9.2. Use of the AD Bit
1391
1392 The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
1393 response containing a closest (provable) encloser proof in which the
1394 NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
1395
1396 This rule is based on what this closest encloser proof actually
1397 proves: names that would be covered by the Opt-Out NSEC3 RR may or
1398 may not exist as insecure delegations. As such, not all the data in
1399 responses containing such closest encloser proofs will have been
1400 cryptographically verified, so the AD bit cannot be set.
1401
1402 10. Special Considerations
1403
1404 10.1. Domain Name Length Restrictions
1405
1406 Zones signed using this specification have additional domain name
1407 length restrictions imposed upon them. In particular, zones with
1408 names that, when converted into hashed owner names exceed the 255
1409 octet length limit imposed by [RFC1035], cannot use this
1410 specification.
1411
1412 The actual maximum length of a domain name in a particular zone
1413 depends on both the length of the zone name (versus the whole domain
1414 name) and the particular hash function used.
1415
1416 As an example, SHA-1 produces a hash of 160 bits. The base-32
1417 encoding of 160 bits results in 32 characters. The 32 characters are
1418 prepended to the name of the zone as a single label, which includes a
1419 length field of a single octet. The maximum length of the zone name,
1420 when using SHA-1, is 222 octets (255 - 33).
1421
1422
1423
1424
1425
1426
1427 Laurie, et al. Standards Track [Page 26]
1428 RFC 5155 NSEC3 March 2008
1429
1430
1431 10.2. DNAME at the Zone Apex
1432
1433 The DNAME specification in Section 3 of [RFC2672] has a 'no-
1434 descendants' limitation. If a DNAME RR is present at node N, there
1435 MUST be no data at any descendant of N.
1436
1437 If N is the apex of the zone, there will be NSEC3 and RRSIG types
1438 present at descendants of N. This specification updates the DNAME
1439 specification to allow NSEC3 and RRSIG types at descendants of the
1440 apex regardless of the existence of DNAME at the apex.
1441
1442 10.3. Iterations
1443
1444 Setting the number of iterations used allows the zone owner to choose
1445 the cost of computing a hash, and therefore the cost of generating a
1446 dictionary. Note that this is distinct from the effect of salt,
1447 which prevents the use of a single precomputed dictionary for all
1448 time.
1449
1450 Obviously the number of iterations also affects the zone owner's cost
1451 of signing and serving the zone as well as the validator's cost of
1452 verifying responses from the zone. We therefore impose an upper
1453 limit on the number of iterations. We base this on the number of
1454 iterations that approximates the cost of verifying an RRSet.
1455
1456 The limits, therefore, are based on the size of the smallest zone
1457 signing key, rounded up to the nearest table value (or rounded down
1458 if the key is larger than the largest table value).
1459
1460 A zone owner MUST NOT use a value higher than shown in the table
1461 below for iterations for the given key size. A resolver MAY treat a
1462 response with a higher value as insecure, after the validator has
1463 verified that the signature over the NSEC3 RR is correct.
1464
1465 +----------+------------+
1466 | Key Size | Iterations |
1467 +----------+------------+
1468 | 1024 | 150 |
1469 | 2048 | 500 |
1470 | 4096 | 2,500 |
1471 +----------+------------+
1472
1473 This table is based on an approximation of the ratio between the cost
1474 of an SHA-1 calculation and the cost of an RSA verification for keys
1475 of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
1476 (2500 to 1).
1477
1478
1479
1480
1481
1482 Laurie, et al. Standards Track [Page 27]
1483 RFC 5155 NSEC3 March 2008
1484
1485
1486 The ratio between SHA-1 calculation and DSA verification is higher
1487 (1500 to 1 for keys of size 1024). A higher iteration count degrades
1488 performance, while DSA verification is already more expensive than
1489 RSA for the same key size. Therefore the values in the table MUST be
1490 used independent of the key algorithm.
1491
1492 10.4. Transitioning a Signed Zone from NSEC to NSEC3
1493
1494 When transitioning an already signed and trusted zone to this
1495 specification, care must be taken to prevent client validation
1496 failures during the process.
1497
1498 The basic procedure is as follows:
1499
1500 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases
1501 described in Section 2. The actual method for safely and
1502 securely changing the DNSKEY RRSet of the zone is outside the
1503 scope of this specification. However, the end result MUST be
1504 that all DS RRs in the parent use the specified algorithm
1505 aliases.
1506
1507 After this transition is complete, all NSEC3-unaware clients will
1508 treat the zone as insecure. At this point, the authoritative
1509 server still returns negative and wildcard responses that contain
1510 NSEC RRs.
1511
1512 2. Add signed NSEC3 RRs to the zone, either incrementally or all at
1513 once. If adding incrementally, then the last RRSet added MUST be
1514 the NSEC3PARAM RRSet.
1515
1516 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to
1517 serving negative and wildcard responses with NSEC3 RRs according
1518 to this specification.
1519
1520 4. Remove the NSEC RRs either incrementally or all at once.
1521
1522 10.5. Transitioning a Signed Zone from NSEC3 to NSEC
1523
1524 To safely transition back to a DNSSEC [RFC4035] signed zone, simply
1525 reverse the procedure above:
1526
1527 1. Add NSEC RRs incrementally or all at once.
1528
1529 2. Remove the NSEC3PARAM RRSet. This will signal the server to use
1530 the NSEC RRs for negative and wildcard responses.
1531
1532 3. Remove the NSEC3 RRs either incrementally or all at once.
1533
1534
1535
1536
1537 Laurie, et al. Standards Track [Page 28]
1538 RFC 5155 NSEC3 March 2008
1539
1540
1541 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
1542 After this transition is complete, all NSEC3-unaware clients will
1543 treat the zone as secure.
1544
8.5. Validating No Data Responses, QTYPE is not DS If there is an NSEC3 RR that matches QNAME present, the validator must check that both the QTYPE and the CNAME type are not set in its Type Bit Maps field. Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field. If there is no NSEC3 RR present that matches QNAME, then the validator MUST verify a closest provable encloser proof for the QNAME. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name. This test covers the case where the response is due to an Empty Non-Terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR.
7.2.3. No Data Responses, QTYPE is not DS If the No Data Response is a result of an empty non-terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. In all other cases, the server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field.
8.5. Validating No Data Responses, QTYPE is not DS If there is no NSEC3 RR present that matches QNAME, then the validator MUST verify a closest provable encloser proof for the QNAME. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name. This test covers the case where the response is due to an Empty Non-Terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR. If there is an NSEC3 RR that matches QNAME present, the validator must check that both the QTYPE and the CNAME type are not set in its Type Bit Maps field. Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field.
1545 11. IANA Considerations
1546
1547 Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
1548 parameter, this document does not define a particular mechanism for
1549 safely transitioning from one NSEC3 hash algorithm to another. When
1550 specifying a new hash algorithm for use with NSEC3, a transition
1551 mechanism MUST also be defined.
1552
1553 This document updates the IANA registry "DOMAIN NAME SYSTEM
1554 PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
1555 registry "TYPES", by defining two new types. Section 3 defines the
1556 NSEC3 RR type 50. Section 4 defines the NSEC3PARAM RR type 51.
1557
1558 This document updates the IANA registry "DNS SECURITY ALGORITHM
1559 NUMBERS -- per [RFC4035]"
1560 (http://www.iana.org/assignments/dns-sec-alg-numbers). Section 2
1561 defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
1562 respectively existing registrations DSA and RSASHA1 in combination
1563 with NSEC3 hash algorithm SHA1.
1564
1565 Since these algorithm numbers are aliases for existing DNSKEY
1566 algorithm numbers, the flags that exist for the original algorithm
1567 are valid for the alias algorithm.
1568
1569 This document creates a new IANA registry for NSEC3 flags. This
1570 registry is named "DNSSEC NSEC3 Flags". The initial contents of this
1571 registry are:
1572
1573 0 1 2 3 4 5 6 7
1574 +---+---+---+---+---+---+---+---+
1575 | | | | | | | |Opt|
1576 | | | | | | | |Out|
1577 +---+---+---+---+---+---+---+---+
1578
1579 bit 7 is the Opt-Out flag.
1580
1581 bits 0 - 6 are available for assignment.
1582
1583 Assignment of additional NSEC3 Flags in this registry requires IETF
1584 Standards Action [RFC2434].
1585
1586 This document creates a new IANA registry for NSEC3PARAM flags. This
1587 registry is named "DNSSEC NSEC3PARAM Flags". The initial contents of
1588 this registry are:
1589
1590
1591
1592 Laurie, et al. Standards Track [Page 29]
1593 RFC 5155 NSEC3 March 2008
1594
1595
1596 0 1 2 3 4 5 6 7
1597 +---+---+---+---+---+---+---+---+
1598 | | | | | | | | 0 |
1599 +---+---+---+---+---+---+---+---+
1600
1601 bit 7 is reserved and must be 0.
1602
1603 bits 0 - 6 are available for assignment.
1604
1605 Assignment of additional NSEC3PARAM Flags in this registry requires
1606 IETF Standards Action [RFC2434].
1607
1608 Finally, this document creates a new IANA registry for NSEC3 hash
1609 algorithms. This registry is named "DNSSEC NSEC3 Hash Algorithms".
1610 The initial contents of this registry are:
1611
1612 0 is Reserved.
1613
1614 1 is SHA-1.
1615
1616 2-255 Available for assignment.
1617
1618 Assignment of additional NSEC3 hash algorithms in this registry
1619 requires IETF Standards Action [RFC2434].
1620
1621 12. Security Considerations
1622
1623 12.1. Hashing Considerations
1624
1625 12.1.1. Dictionary Attacks
1626
1627 The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
1628 attacker retrieves all the NSEC3 RRs, then calculates the hashes of
1629 all likely domain names, comparing against the hashes found in the
1630 NSEC3 RRs, and thus enumerating the zone). These are substantially
1631 more expensive than enumerating the original NSEC RRs would have
1632 been, and in any case, such an attack could also be used directly
1633 against the name server itself by performing queries for all likely
1634 names, though this would obviously be more detectable. The expense
1635 of this off-line attack can be chosen by setting the number of
1636 iterations in the NSEC3 RR.
1637
1638 Zones are also susceptible to a pre-calculated dictionary attack --
1639 that is, a list of hashes for all likely names is computed once, then
1640 NSEC3 RR is scanned periodically and compared against the precomputed
1641 hashes. This attack is prevented by changing the salt on a regular
1642 basis.
1643
1644
1645
1646
1647 Laurie, et al. Standards Track [Page 30]
1648 RFC 5155 NSEC3 March 2008
1649
1650
1651 The salt SHOULD be at least 64 bits long and unpredictable, so that
1652 an attacker cannot anticipate the value of the salt and compute the
1653 next set of dictionaries before the zone is published.
1654
1655 12.1.2. Collisions
1656
1657 Hash collisions between QNAME and the owner name of an NSEC3 RR may
1658 occur. When they do, it will be impossible to prove the non-
1659 existence of the colliding QNAME. However, with SHA-1, this is
1660 highly unlikely (on the order of 1 in 2^160). Note that DNSSEC
1661 already relies on the presumption that a cryptographic hash function
1662 is second pre-image resistant, since these hash functions are used
1663 for generating and validating signatures and DS RRs.
1664
1665 12.1.3. Transitioning to a New Hash Algorithm
1666
1667 Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
1668 parameter, this document does not define a particular mechanism for
1669 safely transitioning from one NSEC3 hash algorithm to another. When
1670 specifying a new hash algorithm for use with NSEC3, a transition
1671 mechanism MUST also be defined. It is possible that the only
1672 practical and palatable transition mechanisms may require an
1673 intermediate transition to an insecure state, or to a state that uses
1674 NSEC records instead of NSEC3.
1675
1676 12.1.4. Using High Iteration Values
1677
1678 Since validators should treat responses containing NSEC3 RRs with
1679 high iteration values as insecure, presence of just one signed NSEC3
1680 RR with a high iteration value in a zone provides attackers with a
1681 possible downgrade attack.
1682
1683 The attack is simply to remove any existing NSEC3 RRs from a
1684 response, and replace or add a single (or multiple) NSEC3 RR that
1685 uses a high iterations value to the response. Validators will then
1686 be forced to treat the response as insecure. This attack would be
1687 effective only when all of following conditions are met:
1688
1689 o There is at least one signed NSEC3 RR that uses a high iterations
1690 value present in the zone.
1691
1692 o The attacker has access to one or more of these NSEC3 RRs. This
1693 is trivially true when the NSEC3 RRs with high iteration values
1694 are being returned in typical responses, but may also be true if
1695 the attacker can access the zone via AXFR or IXFR queries, or any
1696 other methodology.
1697
1698
1699
1700
1701
1702 Laurie, et al. Standards Track [Page 31]
1703 RFC 5155 NSEC3 March 2008
1704
1705
1706 Using a high number of iterations also introduces an additional
1707 denial-of-service opportunity against servers, since servers must
1708 calculate several hashes per negative or wildcard response.
1709
1710 12.2. Opt-Out Considerations
1711
1712 The Opt-Out Flag (O) allows for unsigned names, in the form of
1713 delegations to unsigned zones, to exist within an otherwise signed
1714 zone. All unsigned names are, by definition, insecure, and their
1715 validity or existence cannot be cryptographically proven.
1716
1717 In general:
1718
1719 o Resource records with unsigned names (whether existing or not)
1720 suffer from the same vulnerabilities as RRs in an unsigned zone.
1721 These vulnerabilities are described in more detail in [RFC3833]
1722 (note in particular Section 2.3, "Name Chaining" and Section 2.6,
1723 "Authenticated Denial of Domain Names").
1724
1725 o Resource records with signed names have the same security whether
1726 or not Opt-Out is used.
1727
1728 Note that with or without Opt-Out, an insecure delegation may be
1729 undetectably altered by an attacker. Because of this, the primary
1730 difference in security when using Opt-Out is the loss of the ability
1731 to prove the existence or nonexistence of an insecure delegation
1732 within the span of an Opt-Out NSEC3 RR.
1733
1734 In particular, this means that a malicious entity may be able to
1735 insert or delete RRs with unsigned names. These RRs are normally NS
1736 RRs, but this also includes signed wildcard expansions (while the
1737 wildcard RR itself is signed, its expanded name is an unsigned name).
1738
1739 Note that being able to add a delegation is functionally equivalent
1740 to being able to add any RR type: an attacker merely has to forge a
1741 delegation to name server under his/her control and place whatever
1742 RRs needed at the subzone apex.
1743
1744 While in particular cases, this issue may not present a significant
1745 security problem, in general it should not be lightly dismissed.
1746 Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
1747 In particular, zone signing tools SHOULD NOT default to using Opt-
1748 Out, and MAY choose to not support Opt-Out at all.
1749
1750
1751
1752
1753
1754
1755
1756
1757 Laurie, et al. Standards Track [Page 32]
1758 RFC 5155 NSEC3 March 2008
1759
1760
1761 12.3. Other Considerations
1762
1763 Walking the NSEC3 RRs will reveal the total number of RRs in the zone
1764 (plus empty non-terminals), and also what types there are. This
1765 could be mitigated by adding dummy entries, but certainly an upper
1766 limit can always be found.
1767
1768 13. References
1769
1770 13.1. Normative References
1771
1772 [RFC1034] Mockapetris, P., "Domain names - concepts and
1773 facilities", STD 13, RFC 1034, November 1987.
1774
1775 [RFC1035] Mockapetris, P., "Domain names - implementation and
1776 specification", STD 13, RFC 1035, November 1987.
1777
1778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1779 Requirement Levels", BCP 14, RFC 2119, March 1997.
1780
1781 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1782 "Dynamic Updates in the Domain Name System (DNS
1783 UPDATE)", RFC 2136, April 1997.
1784
1785 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1786 Specification", RFC 2181, July 1997.
1787
1788 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1789 NCACHE)", RFC 2308, March 1998.
1790
1791 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
1792 Writing an IANA Considerations Section in RFCs",
1793 BCP 26, RFC 2434, October 1998.
1794
1795 [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
1796 "Domain Name System (DNS) IANA Considerations",
1797 BCP 42, RFC 2929, September 2000.
1798
1799 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
1800 Record (RR) Types", RFC 3597, September 2003.
1801
1802 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D.,
1803 and S. Rose, "DNS Security Introduction and
1804 Requirements", RFC 4033, March 2005.
1805
1806 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D.,
1807 and S. Rose, "Resource Records for the DNS Security
1808 Extensions", RFC 4034, March 2005.
1809
1810
1811
1812 Laurie, et al. Standards Track [Page 33]
1813 RFC 5155 NSEC3 March 2008
1814
1815
1816 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D.,
1817 and S. Rose, "Protocol Modifications for the DNS
1818 Security Extensions", RFC 4035, March 2005.
1819
1820 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
1821 Encodings", RFC 4648, October 2006.
1822
1823 13.2. Informative References
1824
1825 [DNSEXT-NO] Josefsson, S., "Authenticating Denial of Existence
1826 in DNS with Minimum Disclosure", Work in Progress,
1827 July 2000.
1828
1829 [DNSEXT-NSEC2v2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
1830 Work in Progress, December 2004.
1831
1832 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
1833 RFC 2672, August 1999.
1834
1835 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
1836 Specification Version 2.0", RFC 2898,
1837 September 2000.
1838
1839 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
1840 Domain Name System (DNS)", RFC 3833, August 2004.
1841
1842 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain
1843 Name System", RFC 4592, July 2006.
1844
1845 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS
1846 Security (DNSSEC) Opt-In", RFC 4956, July 2007.
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867 Laurie, et al. Standards Track [Page 34]
1868 RFC 5155 NSEC3 March 2008
1869
1870
The IANA registry is at https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml
RFC9157 updates the IANA considerations Section 4 of that document says: " In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" registry, the registration procedure for "DNSSEC NSEC3 Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" has been changed from "Standards Action" to "RFC Required", and this document has been added as a reference."
1871 Appendix A. Example Zone
1872
1873 This is a zone showing its NSEC3 RRs. They can also be used as test
1874 vectors for the hash algorithm.
1875
1876 The overall TTL and class are specified in the SOA RR, and are
1877 subsequently omitted for clarity.
1878
1879 The zone is preceded by a list that contains the hashes of the
1880 original ownernames.
1881
The example in Appendix A has an NSEC3 next hashed owner name field with the non-base 32 characters 9, 0, and 1.
The example should be changed so that the field in question is valid base 32.
--VERIFIER NOTES-- The example actually uses base32hex (see RFC 4648) and is, therefore, valid.
1882 ; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
1883 ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl
1884 ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi
1885 ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
1886 ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r
1887 ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
1888 ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
1889 ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
1890 ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc
1891 ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
1892 ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv
1893 ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
1894 ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
1895 example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 (
1896 3600000 3600 )
1897 RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
1898 40430 example.
1899 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
1900 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
1901 VI2LmKusbZsT0Q== )
1902 NS ns1.example.
1903 NS ns2.example.
1904 RRSIG NS 7 1 3600 20150420235959 20051021000000 (
1905 40430 example.
1906 PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
1907 qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
1908 CnMXjtz6SyObxA== )
1909 MX 1 xx.example.
1910 RRSIG MX 7 1 3600 20150420235959 20051021000000 (
1911 40430 example.
1912 GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
1913 9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
1914 n9Mto/Kx+wBo+w== )
1915 DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
1916 sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
1917 TY4hHn9npWFRw5BYubE= )
1918
1919
1920
1921
1922 Laurie, et al. Standards Track [Page 35]
1923 RFC 5155 NSEC3 March 2008
1924
1925
1926 DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
1927 j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
1928 AbsUdblMFin8CVF3n4s= )
1929 RRSIG DNSKEY 7 1 3600 20150420235959 (
1930 20051021000000 12708 example.
1931 AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
1932 uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
1933 MGQZf3bH+QsCtg== )
1934 NSEC3PARAM 1 0 12 aabbccdd
1935 RRSIG NSEC3PARAM 7 1 3600 20150420235959 (
1936 20051021000000 40430 example.
1937 C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
1938 rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
1939 TLQsjlkynhG6Cg== )
1940 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
1941 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
1942 SOA NSEC3PARAM RRSIG )
1943 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
1944 40430 example.
1945 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
1946 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
1947 BOCXJZMnpuwhpA== )
1948 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
1949 RRSIG A 7 2 3600 20150420235959 20051021000000 (
1950 40430 example.
1951 h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
1952 K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
1953 k8p6xHMPZumXlw== )
1954 NSEC3 1 1 12 aabbccdd (
1955 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
1956 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
1957 40430 example.
1958 OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
1959 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
1960 NI6mRk/r1dOSUw== )
1961 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
1962 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
1963 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
1964 40430 example.
1965 KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
1966 VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
1967 TuktZ+sdsZPY1w== )
1968 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
1969 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
1970
1971
1972
1973
1974
1975
1976
1977 Laurie, et al. Standards Track [Page 36]
1978 RFC 5155 NSEC3 March 2008
1979
1980
1981 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
1982 40430 example.
1983 g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
1984 Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
1985 XtAIR3chwgW+SA== )
1986 a.example. NS ns1.a.example.
1987 NS ns2.a.example.
1988 DS 58470 5 1 (
1989 3079F1593EBAD6DC121E202A8B766A6A4837206C )
1990 RRSIG DS 7 2 3600 20150420235959 20051021000000 (
1991 40430 example.
1992 XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
1993 M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
1994 o722vZ4UZ2dIdA== )
1995 ns1.a.example. A 192.0.2.5
1996 ns2.a.example. A 192.0.2.6
1997 ai.example. A 192.0.2.9
1998 RRSIG A 7 2 3600 20150420235959 20051021000000 (
1999 40430 example.
2000 hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
2001 tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
2002 rznEn8sQ64UdqA== )
2003 HINFO "KLH-10" "ITS"
2004 RRSIG HINFO 7 2 3600 20150420235959 20051021000000 (
2005 40430 example.
2006 Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
2007 enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
2008 v0wLHpEZG7Xj2w== )
2009 AAAA 2001:db8:0:0:0:0:f00:baa9
2010 RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
2011 40430 example.
2012 LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
2013 uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
2014 cHueLuXkMjBArQ== )
2015 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
2016 gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
2017 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2018 40430 example.
2019 ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
2020 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
2021 pOv0TSTyiTxIZg== )
2022 c.example. NS ns1.c.example.
2023 NS ns2.c.example.
2024 ns1.c.example. A 192.0.2.7
2025 ns2.c.example. A 192.0.2.8
2026 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
2027 ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
2028 RRSIG )
2029
2030
2031
2032 Laurie, et al. Standards Track [Page 37]
2033 RFC 5155 NSEC3 March 2008
2034
2035
2036 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2037 40430 example.
2038 IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
2039 LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
2040 Dy+rdGIeRSVNyw== )
2041 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
2042 k8udemvp1j2f7eg6jebps17vp3n8i58h )
2043 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2044 40430 example.
2045 gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
2046 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
2047 MpzVSKfTwx4uYA== )
2048 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
2049 kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
2050 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2051 40430 example.
2052 FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
2053 S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
2054 Otx7w9WfcIg62A== )
2055 kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
2056 q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
2057 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2058 40430 example.
2059 VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
2060 6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
2061 QJazmASFKGxGXg== )
2062 ns1.example. A 192.0.2.1
2063 RRSIG A 7 2 3600 20150420235959 20051021000000 (
2064 40430 example.
2065 bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
2066 kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
2067 4FRvZR9SCFHF5Q== )
2068 ns2.example. A 192.0.2.2
2069 RRSIG A 7 2 3600 20150420235959 20051021000000 (
2070 40430 example.
2071 ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
2072 zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
2073 4IHfeX6n8vfoGA== )
2074 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2075 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2076 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2077 40430 example.
2078 hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2079 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2080 NlkxWcLsIlMmUg== )
2081
2082
2083
2084
2085
2086
2087 Laurie, et al. Standards Track [Page 38]
2088 RFC 5155 NSEC3 March 2008
2089
2090
2091 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
2092 t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
2093 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2094 40430 example.
2095 aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
2096 ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
2097 HF1FWKW7RIJdtQ== )
2098 t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
2099 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
2100 RRSIG )
2101 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
2102 40430 example.
2103 RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
2104 fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
2105 X1xPl1ATNa+8Dw== )
2106 *.w.example. MX 1 ai.example.
2107 RRSIG MX 7 2 3600 20150420235959 20051021000000 (
2108 40430 example.
2109 CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
2110 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
2111 ivEBP6+4KS3ldA== )
2112 x.w.example. MX 1 xx.example.
2113 RRSIG MX 7 3 3600 20150420235959 20051021000000 (
2114 40430 example.
2115 IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
2116 QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
2117 7WCtwwekLKRAwQ== )
2118 x.y.w.example. MX 1 xx.example.
2119 RRSIG MX 7 4 3600 20150420235959 20051021000000 (
2120 40430 example.
2121 MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
2122 nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
2123 8/8Ccl2Zn2hbug== )
2124 xx.example. A 192.0.2.10
2125 RRSIG A 7 2 3600 20150420235959 20051021000000 (
2126 40430 example.
2127 T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
2128 YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
2129 pQvhq+Ac6+ZiFg== )
2130 HINFO "KLH-10" "TOPS-20"
2131 RRSIG HINFO 7 2 3600 20150420235959 20051021000000 (
2132 40430 example.
2133 KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
2134 FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
2135 6Jfqj/8NzWjvKg== )
2136 AAAA 2001:db8:0:0:0:0:f00:baaa
2137
2138
2139
2140
2141
2142 Laurie, et al. Standards Track [Page 39]
2143 RFC 5155 NSEC3 March 2008
2144
2145
2146 RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
2147 40430 example.
2148 IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
2149 uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
2150 NzYfMItpILl/Xw== )
2151
2152 Appendix B. Example Responses
2153
2154 The examples in this section show response messages using the signed
2155 zone example in Appendix A.
2156
2157 B.1. Name Error
2158
2159 An authoritative name error. The NSEC3 RRs prove that the name does
2160 not exist and that there is no wildcard RR that should have been
2161 expanded.
2162
2163 ;; Header: QR AA DO RCODE=3
2164 ;;
2165 ;; Question
2166 a.c.x.w.example. IN A
2167
2168 ;; Answer
2169 ;; (empty)
2170
2171 ;; Authority
2172
2173 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2174 3600000 3600 )
2175 example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2176 40430 example.
2177 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2178 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2179 VI2LmKusbZsT0Q== )
2180
2181 ;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
2182 ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
2183
2184 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2185 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2186 SOA NSEC3PARAM RRSIG )
2187 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
2188 20150420235959 20051021000000 40430 example.
2189 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2190 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2191 BOCXJZMnpuwhpA== )
2192
2193
2194
2195
2196
2197 Laurie, et al. Standards Track [Page 40]
2198 RFC 5155 NSEC3 March 2008
2199
2200
2201 ;; NSEC3 RR that matches the closest encloser (x.w.example)
2202 ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
2203
2204 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
2205 gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
2206 b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
2207 20150420235959 20051021000000 40430 example.
2208 ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
2209 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
2210 pOv0TSTyiTxIZg== )
2211
2212 ;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
2213 ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
2214
2215 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2216 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
2217 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
2218 20150420235959 20051021000000 40430 example.
2219 g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2220 Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2221 XtAIR3chwgW+SA== )
2222
2223 ;; Additional
2224 ;; (empty)
2225
2226 The query returned three NSEC3 RRs that prove that the requested data
2227 does not exist and that no wildcard expansion applies. The negative
2228 response is authenticated by verifying the NSEC3 RRs. The
2229 corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
2230 "example" DNSKEY of algorithm 7 and with key tag 40430. The resolver
2231 needs the corresponding DNSKEY RR in order to authenticate this
2232 answer.
2233
2234 One of the owner names of the NSEC3 RRs matches the closest encloser.
2235 One of the NSEC3 RRs prove that there exists no longer name. One of
2236 the NSEC3 RRs prove that there exists no wildcard RRSets that should
2237 have been expanded. The closest encloser can be found by applying
2238 the algorithm in Section 8.3.
2239
2240 In the above example, the name 'x.w.example' hashes to
2241 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might
2242 be the closest encloser. To prove that 'c.x.w.example' and
2243 '*.x.w.example' do not exist, these names are hashed to,
2244 respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
2245 '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs
2246 prove that these hashed owner names do not exist.
2247
2248
2249
2250
2251
2252 Laurie, et al. Standards Track [Page 41]
2253 RFC 5155 NSEC3 March 2008
2254
2255
2256 B.2. No Data Error
2257
2258 A "no data" response. The NSEC3 RR proves that the name exists and
2259 that the requested RR type does not.
2260
2261 ;; Header: QR AA DO RCODE=0
2262 ;;
2263 ;; Question
2264 ns1.example. IN MX
2265
2266 ;; Answer
2267 ;; (empty)
2268
2269 ;; Authority
2270 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2271 3600000 3600 )
2272 example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2273 40430 example.
2274 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2275 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2276 VI2LmKusbZsT0Q== )
2277
2278 ;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
2279
2280 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
2281 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
2282 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
2283 20150420235959 20051021000000 40430 example.
2284 OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
2285 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
2286 NI6mRk/r1dOSUw== )
2287 ;; Additional
2288 ;; (empty)
2289
2290 The query returned an NSEC3 RR that proves that the requested name
2291 exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
2292 but the requested RR type does not exist (type MX is absent in the
2293 type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
2294 also absent in the type code list of the NSEC3 RR).
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307 Laurie, et al. Standards Track [Page 42]
2308 RFC 5155 NSEC3 March 2008
2309
2310
2311 B.2.1. No Data Error, Empty Non-Terminal
2312
2313 A "no data" response because of an empty non-terminal. The NSEC3 RR
2314 proves that the name exists and that the requested RR type does not.
2315
2316 ;; Header: QR AA DO RCODE=0
2317 ;;
2318 ;; Question
2319 y.w.example. IN A
2320
2321 ;; Answer
2322 ;; (empty)
2323
2324 ;; Authority
2325 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2326 3600000 3600 )
2327 example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2328 40430 example.
2329 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2330 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2331 VI2LmKusbZsT0Q== )
2332
2333 ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
2334
2335 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
2336 k8udemvp1j2f7eg6jebps17vp3n8i58h )
2337 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
2338 20150420235959 20051021000000 40430 example.
2339 gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
2340 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
2341 MpzVSKfTwx4uYA== )
2342
2343 ;; Additional
2344 ;; (empty)
2345
2346 The query returned an NSEC3 RR that proves that the requested name
2347 exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
2348 but the requested RR type does not exist (Type A is absent in the
2349 Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty
2350 non-terminal proof using NSECs, this is identical to a No Data Error.
2351 This example is solely mentioned to be complete.
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362 Laurie, et al. Standards Track [Page 43]
2363 RFC 5155 NSEC3 March 2008
2364
2365
2366 B.3. Referral to an Opt-Out Unsigned Zone
2367
2368 The NSEC3 RRs prove that nothing for this delegation was signed.
2369 There is no proof that the unsigned delegation exists.
2370
2371 ;; Header: QR DO RCODE=0
2372 ;;
2373 ;; Question
2374 mc.c.example. IN MX
2375
2376 ;; Answer
2377 ;; (empty)
2378
2379 ;; Authority
2380 c.example. NS ns1.c.example.
2381 NS ns2.c.example.
2382
2383 ;; NSEC3 RR that covers the "next closer" name (c.example)
2384 ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
2385
2386 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2387 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
2388 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
2389 20150420235959 20051021000000 40430 example.
2390 g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2391 Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2392 XtAIR3chwgW+SA== )
2393
2394 ;; NSEC3 RR that matches the closest encloser (example)
2395 ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
2396
2397 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2398 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2399 SOA NSEC3PARAM RRSIG )
2400 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
2401 20150420235959 20051021000000 40430 example.
2402 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2403 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2404 BOCXJZMnpuwhpA== )
2405
2406 ;; Additional
2407 ns1.c.example. A 192.0.2.7
2408 ns2.c.example. A 192.0.2.8
2409
2410 The query returned a referral to the unsigned "c.example." zone. The
2411 response contains the closest provable encloser of "c.example" to be
2412 "example", since the hash of "c.example"
2413
2414
2415
2416
2417 Laurie, et al. Standards Track [Page 44]
2418 RFC 5155 NSEC3 March 2008
2419
2420
2421 ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
2422 and its Opt-Out bit is set.
2423
2424 B.4. Wildcard Expansion
2425
2426 A query that was answered with a response containing a wildcard
2427 expansion. The label count in the RRSIG RRSet in the answer section
2428 indicates that a wildcard RRSet was expanded to produce this
2429 response, and the NSEC3 RR proves that no "next closer" name exists
2430 in the zone.
2431
2432 ;; Header: QR AA DO RCODE=0
2433 ;;
2434 ;; Question
2435 a.z.w.example. IN MX
2436
2437 ;; Answer
2438 a.z.w.example. MX 1 ai.example.
2439 a.z.w.example. RRSIG MX 7 2 3600 20150420235959 20051021000000 (
2440 40430 example.
2441 CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
2442 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
2443 ivEBP6+4KS3ldA== )
2444
2445 ;; Authority
2446 example. NS ns1.example.
2447 example. NS ns2.example.
2448 example. RRSIG NS 7 1 3600 20150420235959 20051021000000 (
2449 40430 example.
2450 PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
2451 qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
2452 CnMXjtz6SyObxA== )
2453
2454 ;; NSEC3 RR that covers the "next closer" name (z.w.example)
2455 ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
2456
2457 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2458 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2459 q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
2460 20150420235959 20051021000000 40430 example.
2461 hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2462 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2463 NlkxWcLsIlMmUg== )
2464
2465
2466
2467
2468
2469
2470
2471
2472 Laurie, et al. Standards Track [Page 45]
2473 RFC 5155 NSEC3 March 2008
2474
2475
2476 ;; Additional
2477 ai.example. A 192.0.2.9
2478 ai.example. RRSIG A 7 2 3600 20150420235959 20051021000000 (
2479 40430 example.
2480 hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
2481 tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
2482 rznEn8sQ64UdqA== )
2483 ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9
2484 ai.example. RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
2485 40430 example.
2486 LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
2487 uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
2488 cHueLuXkMjBArQ== )
2489
2490 The query returned an answer that was produced as a result of a
2491 wildcard expansion. The answer section contains a wildcard RRSet
2492 expanded as it would be in a traditional DNS response. The RRSIG
2493 Labels field value of 2 indicates that the answer is the result of a
2494 wildcard expansion, as the "a.z.w.example" name contains 4 labels.
2495 This also shows that "w.example" exists, so there is no need for an
2496 NSEC3 RR that matches the closest encloser.
2497
2498 The NSEC3 RR proves that no closer match could have been used to
2499 answer this query.
2500
2501 B.5. Wildcard No Data Error
2502
2503 A "no data" response for a name covered by a wildcard. The NSEC3 RRs
2504 prove that the matching wildcard name does not have any RRs of the
2505 requested type and that no closer match exists in the zone.
2506
2507 ;; Header: QR AA DO RCODE=0
2508 ;;
2509 ;; Question
2510 a.z.w.example. IN AAAA
2511
2512 ;; Answer
2513 ;; (empty)
2514
2515 ;; Authority
2516 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2517 3600000 3600 )
2518 example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2519 40430 example.
2520 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2521 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2522 VI2LmKusbZsT0Q== )
2523
2524
2525
2526
2527 Laurie, et al. Standards Track [Page 46]
2528 RFC 5155 NSEC3 March 2008
2529
2530
2531 ;; NSEC3 RR that matches the closest encloser (w.example)
2532 ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
2533
2534 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
2535 kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
2536 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
2537 20150420235959 20051021000000 40430 example.
2538 FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
2539 S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
2540 Otx7w9WfcIg62A== )
2541
2542 ;; NSEC3 RR that covers the "next closer" name (z.w.example)
2543 ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
2544
2545 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2546 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2547 q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
2548 20150420235959 20051021000000 40430 example.
2549 hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2550 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2551 NlkxWcLsIlMmUg== )
2552
2553 ;; NSEC3 RR that matches a wildcard at the closest encloser.
2554 ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
2555
2556 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
2557 t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
2558 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
2559 20150420235959 20051021000000 40430 example.
2560 aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
2561 ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
2562 HF1FWKW7RIJdtQ== )
2563
2564 ;; Additional
2565 ;; (empty)
2566
2567 The query returned the NSEC3 RRs that prove that the requested data
2568 does not exist and no wildcard RR applies.
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582 Laurie, et al. Standards Track [Page 47]
2583 RFC 5155 NSEC3 March 2008
2584
2585
2586 B.6. DS Child Zone No Data Error
2587
2588 A "no data" response for a QTYPE=DS query that was mistakenly sent to
2589 a name server for the child zone.
2590
2591 ;; Header: QR AA DO RCODE=0
2592 ;;
2593 ;; Question
2594 example. IN DS
2595
2596 ;; Answer
2597 ;; (empty)
2598
2599 ;; Authority
2600 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
2601 3600000 3600 )
2602 example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
2603 40430 example.
2604 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2605 q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2606 VI2LmKusbZsT0Q== )
2607
2608 ;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
2609
2610 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2611 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2612 SOA NSEC3PARAM RRSIG )
2613 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
2614 20150420235959 20051021000000 40430 example.
2615 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2616 IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2617 BOCXJZMnpuwhpA== )
2618
2619 ;; Additional
2620 ;; (empty)
2621
2622 The query returned an NSEC3 RR showing that the requested was
2623 answered by the server authoritative for the zone "example". The
2624 NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
2625 RR is from the apex of the child, not from the zone cut of the
2626 parent. Queries for the "example" DS RRSet should be sent to the
2627 parent servers (which are in this case the root servers).
2628
2629 Appendix C. Special Considerations
2630
2631 The following paragraphs clarify specific behavior and explain
2632 special considerations for implementations.
2633
2634
2635
2636
2637 Laurie, et al. Standards Track [Page 48]
2638 RFC 5155 NSEC3 March 2008
2639
2640
2641 C.1. Salting
2642
2643 Augmenting original owner names with salt before hashing increases
2644 the cost of a dictionary of pre-generated hash-values. For every bit
2645 of salt, the cost of a precomputed dictionary doubles (because there
2646 must be an entry for each word combined with each possible salt
2647 value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
2648 salt, multiplying the cost by 2^2040. This means that an attacker
2649 must, in practice, recompute the dictionary each time the salt is
2650 changed.
2651
2652 Including a salt, regardless of size, does not affect the cost of
2653 constructing NSEC3 RRs. It does increase the size of the NSEC3 RR.
2654
2655 There MUST be at least one complete set of NSEC3 RRs for the zone
2656 using the same salt value.
2657
2658 The salt SHOULD be changed periodically to prevent pre-computation
2659 using a single salt. It is RECOMMENDED that the salt be changed for
2660 every re-signing.
2661
2662 Note that this could cause a resolver to see RRs with different salt
2663 values for the same zone. This is harmless, since each RR stands
2664 alone (that is, it denies the set of owner names whose hashes, using
2665 the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
2666 RR) -- it is only the server that needs a complete set of NSEC3 RRs
2667 with the same salt in order to be able to answer every possible
2668 query.
2669
2670 There is no prohibition with having NSEC3 RRs with different salts
2671 within the same zone. However, in order for authoritative servers to
2672 be able to consistently find covering NSEC3 RRs, the authoritative
2673 server MUST choose a single set of parameters (algorithm, salt, and
2674 iterations) to use when selecting NSEC3 RRs.
2675
2676 C.2. Hash Collision
2677
2678 Hash collisions occur when different messages have the same hash
2679 value. The expected number of domain names needed to give a 1 in 2
2680 chance of a single collision is about 2^(n/2) for a hash of length n
2681 bits (i.e., 2^80 for SHA-1). Though this probability is extremely
2682 low, the following paragraphs deal with avoiding collisions and
2683 assessing possible damage in the event of an attack using hash
2684 collisions.
2685
2686
2687
2688
2689
2690
2691
2692 Laurie, et al. Standards Track [Page 49]
2693 RFC 5155 NSEC3 March 2008
2694
2695
2696 C.2.1. Avoiding Hash Collisions During Generation
2697
2698 During generation of NSEC3 RRs, hash values are supposedly unique.
2699 In the (academic) case of a collision occurring, an alternative salt
2700 MUST be chosen and all hash values MUST be regenerated.
2701
2702 C.2.2. Second Preimage Requirement Analysis
2703
2704 A cryptographic hash function has a second-preimage resistance
2705 property. The second-preimage resistance property means that it is
2706 computationally infeasible to find another message with the same hash
2707 value as a given message, i.e., given preimage X, to find a second
2708 preimage X' != X such that hash(X) = hash(X'). The work factor for
2709 finding a second preimage is of the order of 2^160 for SHA-1. To
2710 mount an attack using an existing NSEC3 RR, an adversary needs to
2711 find a second preimage.
2712
2713 Assuming an adversary is capable of mounting such an extreme attack,
2714 the actual damage is that a response message can be generated that
2715 claims that a certain QNAME (i.e., the second pre-image) does exist,
2716 while in reality QNAME does not exist (a false positive), which will
2717 either cause a security-aware resolver to re-query for the non-
2718 existent name, or to fail the initial query. Note that the adversary
2719 can't mount this attack on an existing name, but only on a name that
2720 the adversary can't choose and that does not yet exist.
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747 Laurie, et al. Standards Track [Page 50]
2748 RFC 5155 NSEC3 March 2008
2749
2750
2751 Authors' Addresses
2752
2753 Ben Laurie
2754 Nominet
2755 17 Perryn Road
2756 London W3 7LR
2757 England
2758
2759 Phone: +44 20 8735 0686
2760 EMail: ben@links.org
2761
2762
2763 Geoffrey Sisson
2764 Nominet
2765 Minerva House
2766 Edmund Halley Road
2767 Oxford Science Park
2768 Oxford OX4 4DQ
2769 UNITED KINGDOM
2770
2771 Phone: +44 1865 332211
2772 EMail: geoff-s@panix.com
2773
2774
2775 Roy Arends
2776 Nominet
2777 Minerva House
2778 Edmund Halley Road
2779 Oxford Science Park
2780 Oxford OX4 4DQ
2781 UNITED KINGDOM
2782
2783 Phone: +44 1865 332211
2784 EMail: roy@nominet.org.uk
2785
2786
2787 David Blacka
2788 VeriSign, Inc.
2789 21355 Ridgetop Circle
2790 Dulles, VA 20166
2791 US
2792
2793 Phone: +1 703 948 3200
2794 EMail: davidb@verisign.com
2795
2796
2797
2798
2799
2800
2801
2802 Laurie, et al. Standards Track [Page 51]
2803 RFC 5155 NSEC3 March 2008
2804
2805
2806 Full Copyright Statement
2807
2808 Copyright (C) The IETF Trust (2008).
2809
2810 This document is subject to the rights, licenses and restrictions
2811 contained in BCP 78, and except as set forth therein, the authors
2812 retain all their rights.
2813
2814 This document and the information contained herein are provided on an
2815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2817 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2818 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2819 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2821
2822 Intellectual Property
2823
2824 The IETF takes no position regarding the validity or scope of any
2825 Intellectual Property Rights or other rights that might be claimed to
2826 pertain to the implementation or use of the technology described in
2827 this document or the extent to which any license under such rights
2828 might or might not be available; nor does it represent that it has
2829 made any independent effort to identify any such rights. Information
2830 on the procedures with respect to rights in RFC documents can be
2831 found in BCP 78 and BCP 79.
2832
2833 Copies of IPR disclosures made to the IETF Secretariat and any
2834 assurances of licenses to be made available, or the result of an
2835 attempt made to obtain a general license or permission for the use of
2836 such proprietary rights by implementers or users of this
2837 specification can be obtained from the IETF on-line IPR repository at
2838 http://www.ietf.org/ipr.
2839
2840 The IETF invites any interested party to bring to its attention any
2841 copyrights, patents or patent applications, or other proprietary
2842 rights that may cover technology that may be required to implement
2843 this standard. Please address the information to the IETF at
2844 ietf-ipr@ietf.org.
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857 Laurie, et al. Standards Track [Page 52]
2858
; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl
; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi
; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r
; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc
; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv
- ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
- ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 (
3600000 3600 )
NS ns1.example.
NS ns2.example.
MX 1 xx.example.
DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
TY4hHn9npWFRw5BYubE= )
DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
AbsUdblMFin8CVF3n4s= )
NSEC3PARAM 1 0 12 aabbccdd:1
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
SOA NSEC3PARAM RRSIG )
! 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
! NSEC3 1 1 12 aabbccdd (
2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
a.example. NS ns1.a.example.
NS ns2.a.example.
DS 58470 5 1 (
3079F1593EBAD6DC121E202A8B766A6A4837206C )
ns1.a.example. A 192.0.2.5
ns2.a.example. A 192.0.2.6
ai.example. A 192.0.2.9
HINFO "KLH-10" "ITS"
AAAA 2001:db8:0:0:0:0:f00:baa9
b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
c.example. NS ns1.c.example.
NS ns2.c.example.
ns1.c.example. A 192.0.2.7
ns2.c.example. A 192.0.2.8
gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
RRSIG )
ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
k8udemvp1j2f7eg6jebps17vp3n8i58h )
k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
! kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
! kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
! q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
ns1.example. A 192.0.2.1
ns2.example. A 192.0.2.2
q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
RRSIG )
*.w.example. MX 1 ai.example.
x.w.example. MX 1 xx.example.
x.y.w.example. MX 1 xx.example.
xx.example. A 192.0.2.10
HINFO "KLH-10" "TOPS-20"
AAAA 2001:db8:0:0:0:0:f00:baaa
; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl
; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi
; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r
; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc
; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv
example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 (
3600000 3600 )
NS ns1.example.
NS ns2.example.
MX 1 xx.example.
DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
TY4hHn9npWFRw5BYubE= )
DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
AbsUdblMFin8CVF3n4s= )
NSEC3PARAM 1 0 12 aabbccdd:1
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
SOA NSEC3PARAM RRSIG )
! 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
a.example. NS ns1.a.example.
NS ns2.a.example.
DS 58470 5 1 (
3079F1593EBAD6DC121E202A8B766A6A4837206C )
ns1.a.example. A 192.0.2.5
ns2.a.example. A 192.0.2.6
ai.example. A 192.0.2.9
HINFO "KLH-10" "ITS"
AAAA 2001:db8:0:0:0:0:f00:baa9
b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
c.example. NS ns1.c.example.
NS ns2.c.example.
ns1.c.example. A 192.0.2.7
ns2.c.example. A 192.0.2.8
gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
RRSIG )
ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
k8udemvp1j2f7eg6jebps17vp3n8i58h )
k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
! q04jkcevqvmu85r014c7dkba38o0ji5r )
ns1.example. A 192.0.2.1
ns2.example. A 192.0.2.2
q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
RRSIG )
*.w.example. MX 1 ai.example.
x.w.example. MX 1 xx.example.
x.y.w.example. MX 1 xx.example.
xx.example. A 192.0.2.10
HINFO "KLH-10" "TOPS-20"
AAAA 2001:db8:0:0:0:0:f00:baaa