1 Internet Engineering Task Force (IETF) W. Hardaker
2 Request for Comments: 9276 USC/ISI
3 BCP: 236 V. Dukhovni
4 Updates: 5155 Bloomberg, L.P.
5 Category: Best Current Practice August 2022
6 ISSN: 2070-1721
7
8
9 Guidance for NSEC3 Parameter Settings
10
11 Abstract
12
13 NSEC3 is a DNSSEC mechanism providing proof of nonexistence by
14 asserting that there are no names that exist between two domain names
15 within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly
16 disclosing the bounding domain name pairs. This document provides
17 guidance on setting NSEC3 parameters based on recent operational
18 deployment experience. This document updates RFC 5155 with guidance
19 about selecting NSEC3 iteration and salt parameters.
20
21 Status of This Memo
22
23 This memo documents an Internet Best Current Practice.
24
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Further information on
29 BCPs is available in Section 2 of RFC 7841.
30
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 https://www.rfc-editor.org/info/rfc9276.
34
35 Copyright Notice
36
37 Copyright (c) 2022 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
39
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (https://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Revised BSD License text as described in Section 4.e of the
47 Trust Legal Provisions and are provided without warranty as described
48 in the Revised BSD License.
49
50 Table of Contents
51
52 1. Introduction
53 1.1. Requirements Notation
54 2. NSEC3 Parameter Value Discussions
55 2.1. Algorithms
56 2.2. Flags
57 2.3. Iterations
58 2.4. Salt
59 3. Recommendations for Deploying and Validating NSEC3 Records
60 3.1. Best Practice for Zone Publishers
61 3.2. Recommendation for Validating Resolvers
62 3.3. Recommendation for Primary and Secondary Relationships
63 4. Security Considerations
64 5. Operational Considerations
65 6. IANA Considerations
66 7. References
67 7.1. Normative References
68 7.2. Informative References
69 Appendix A. Deployment Measurements at Time of Publication
70 Appendix B. Computational Burdens of Processing NSEC3 Iterations
71 Acknowledgments
72 Authors' Addresses
73
74 1. Introduction
75
76 As with NSEC [RFC4035], NSEC3 [RFC5155] provides proof of
77 nonexistence that consists of signed DNS records establishing the
78 nonexistence of a given name or associated Resource Record Type
79 (RRTYPE) in a DNSSEC-signed zone [RFC4035]. However, in the case of
80 NSEC3, the names of valid nodes in the zone are obfuscated through
81 (possibly multiple iterations of) hashing (currently only SHA-1 is in
82 use on the Internet).
83
84 NSEC3 also provides "opt-out support", allowing for blocks of
85 unsigned delegations to be covered by a single NSEC3 record. Use of
86 the opt-out feature allows large registries to only sign as many
87 NSEC3 records as there are signed DS or other Resource Record sets
88 (RRsets) in the zone; with opt-out, unsigned delegations don't
89 require additional NSEC3 records. This sacrifices the tamper-
90 resistance of the proof of nonexistence offered by NSEC3 in order to
91 reduce memory and CPU overheads.
92
93 NSEC3 records have a number of tunable parameters that are specified
94 via an NSEC3PARAM record at the zone apex. These parameters are the
95 hash algorithm, the processing flags, the number of hash iterations,
96 and the salt. Each of these has security and operational
97 considerations that impact both zone owners and validating resolvers.
98 This document provides some best-practice recommendations for setting
99 the NSEC3 parameters.
100
101 1.1. Requirements Notation
102
103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
105 "OPTIONAL" in this document are to be interpreted as described in
106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
107 capitals, as shown here.
108
109 2. NSEC3 Parameter Value Discussions
110
111 The following sections describe the background of the parameters for
112 the NSEC3 and NSEC3PARAM RRTYPEs.
113
114 2.1. Algorithms
115
116 The algorithm field is not discussed by this document. Readers are
117 encouraged to read [RFC8624] for guidance about DNSSEC algorithm
118 usage.
119
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.
120 2.2. Flags
121
122 The NSEC3PARAM flags field currently contains only reserved and
123 unassigned flags. However, individual NSEC3 records contain the
124 "Opt-Out" flag [RFC5155] that specifies whether that NSEC3 record
125 provides proof of nonexistence. In general, NSEC3 with the Opt-Out
126 flag enabled should only be used in large, highly dynamic zones with
127 a small percentage of signed delegations. Operationally, this allows
128 for fewer signature creations when new delegations are inserted into
129 a zone. This is typically only necessary for extremely large
130 registration points providing zone updates faster than real-time
131 signing allows or when using memory-constrained hardware. Operators
132 considering the use of NSEC3 are advised to carefully weigh the costs
133 and benefits of choosing NSEC3 over NSEC. Smaller zones, or large
134 but relatively static zones, are encouraged to not use the opt-opt
135 flag and to take advantage of DNSSEC's authenticated denial of
136 existence.
137
138 2.3. Iterations
139
140 NSEC3 records are created by first hashing the input domain and then
141 repeating that hashing using the same algorithm a number of times
142 based on the iteration parameter in the NSEC3PARAM and NSEC3 records.
143 The first hash with NSEC3 is typically sufficient to discourage zone
144 enumeration performed by "zone walking" an unhashed NSEC chain.
145
146 Note that [RFC5155] describes the Iterations field as follows
147
148 | The Iterations field defines the number of additional times the
149 | hash function has been performed.
150
151 This means that an NSEC3 record with an Iterations field of 0
152 actually requires one hash iteration.
153
154 Only determined parties with significant resources are likely to try
155 and uncover hashed values, regardless of the number of additional
156 iterations performed. If an adversary really wants to expend
157 significant CPU resources to mount an offline dictionary attack on a
158 zone's NSEC3 chain, they'll likely be able to find most of the
159 "guessable" names despite any level of additional hashing iterations.
160
161 Most names published in the DNS are rarely secret or unpredictable.
162 They are published to be memorable, used and consumed by humans.
163 They are often recorded in many other network logs such as email
164 logs, certificate transparency logs, web page links, intrusion-
165 detection systems, malware scanners, email archives, etc. Many times
166 a simple dictionary of commonly used domain names prefixes (www,
167 mail, imap, login, database, etc.) can be used to quickly reveal a
168 large number of labels within a zone. Because of this, there are
169 increasing performance costs yet diminishing returns associated with
170 applying additional hash iterations beyond the first.
171
172 Although Section 10.3 of [RFC5155] specifies the upper bounds for the
173 number of hash iterations to use, there is no published guidance for
174 zone owners about good values to select. Recent academic studies
175 have shown that NSEC3 hashing provides only moderate protection
176 [GPUNSEC3] [ZONEENUM].
177
178 2.4. Salt
179
180 NSEC3 records provide an additional salt value, which can be combined
181 with a Fully Qualified Domain Name (FQDN) to influence the resulting
182 hash, but properties of this extra salt are complicated.
183
184 In cryptography, salts generally add a layer of protection against
185 offline, stored dictionary attacks by combining the value to be
186 hashed with a unique "salt" value. This prevents adversaries from
187 building up and remembering a single dictionary of values that can
188 translate a hash output back to the value that it was derived from.
189
190 In the case of DNS, the situation is different because the hashed
191 names placed in NSEC3 records are always implicitly "salted" by
192 hashing the FQDN from each zone. Thus, no single pre-computed table
193 works to speed up dictionary attacks against multiple target zones.
194 An attacker is always required to compute a complete dictionary per
195 zone, which is expensive in both storage and CPU time.
196
197 To understand the role of the additional NSEC3 salt field, we have to
198 consider how a typical zone walking attack works. Typically, the
199 attack has two phases: online and offline. In the online phase, an
200 attacker "walks the zone" by enumerating (almost) all hashes listed
201 in NSEC3 records and storing them for the offline phase. Then, in
202 the offline cracking phase, the attacker attempts to crack the
203 underlying hash. In this phase, the additional salt value raises the
204 cost of the attack only if the salt value changes during the online
205 phase of the attack. In other words, an additional, constant salt
206 value does not change the cost of the attack.
207
208 Changing a zone's salt value requires the construction of a complete
209 new NSEC3 chain. This is true both when re-signing the entire zone
210 at once and when incrementally signing it in the background where the
211 new salt is only activated once every name in the chain has been
212 completed. As a result, re-salting is a very complex operation, with
213 significant CPU time, memory, and bandwidth consumption. This makes
214 very frequent re-salting impractical and renders the additional salt
215 field functionally useless.
216
217 3. Recommendations for Deploying and Validating NSEC3 Records
218
219 The following subsections describe recommendations for the different
220 operating realms within the DNS.
221
222 3.1. Best Practice for Zone Publishers
223
224 First, if the operational or security features of NSEC3 are not
225 needed, then NSEC SHOULD be used in preference to NSEC3. NSEC3
226 requires greater computational power (see Appendix B) for both
227 authoritative servers and validating clients. Specifically, there is
228 a nontrivial complexity in finding matching NSEC3 records to randomly
229 generated prefixes within a DNS zone. NSEC mitigates this concern.
230 If NSEC3 must be used, then an iterations count of 0 MUST be used to
231 alleviate computational burdens. Note that extra iteration counts
232 other than 0 increase the impact of CPU-exhausting DoS attacks, and
233 also increase the risk of interoperability problems.
234
235 Note that deploying NSEC with minimally covering NSEC records
236 [RFC4470] also incurs a cost, and zone owners should measure the
237 computational difference in deploying either [RFC4470] or NSEC3.
238
239 In short, for all zones, the recommended NSEC3 parameters are as
240 shown below:
241
242 ; SHA-1, no extra iterations, empty salt:
243 ;
244 bcp.example. IN NSEC3PARAM 1 0 0 -
245
246 For small zones, the use of opt-out-based NSEC3 records is NOT
247 RECOMMENDED.
248
249 For very large and sparsely signed zones, where the majority of the
250 records are insecure delegations, opt-out MAY be used.
251
252 Operators SHOULD NOT use a salt by indicating a zero-length salt
253 value instead (represented as a "-" in the presentation format).
254
255 If salts are used, note that since the NSEC3PARAM RR is not used by
256 validating resolvers (see Section 4 of [RFC5155]), the iterations and
257 salt parameters can be changed without the need to wait for RRsets to
258 expire from caches. A complete new NSEC3 chain needs to be
259 constructed and the full zone needs to be re-signed.
260
261 3.2. Recommendation for Validating Resolvers
262
263 Because there has been a large growth of open (public) DNSSEC
264 validating resolvers that are subject to compute resource constraints
265 when handling requests from anonymous clients, this document
266 recommends that validating resolvers reduce their iteration count
267 limits over time. Specifically, validating resolver operators and
268 validating resolver software implementers are encouraged to continue
269 evaluating NSEC3 iteration count deployment trends and lower their
270 acceptable iteration limits over time. Because treating a high
271 iterations count as insecure leaves zones subject to attack,
272 validating resolver operators and validating resolver software
273 implementers are further encouraged to lower their default limit for
274 returning SERVFAIL when processing NSEC3 parameters containing large
275 iteration count values. See Appendix A for measurements taken near
276 the time of publication of this document and potential starting
277 points.
278
279 Validating resolvers MAY return an insecure response to their clients
280 when processing NSEC3 records with iterations larger than 0. Note
281 also that a validating resolver returning an insecure response MUST
282 still validate the signature over the NSEC3 record to ensure the
283 iteration count was not altered since record publication (see
284 Section 10.3 of [RFC5155]).
285
286 Validating resolvers MAY also return a SERVFAIL response when
287 processing NSEC3 records with iterations larger than 0. Validating
288 resolvers MAY choose to ignore authoritative server responses with
289 iteration counts greater than 0, which will likely result in
290 returning a SERVFAIL to the client when no acceptable responses are
291 received from authoritative servers.
292
293 Validating resolvers returning an insecure or SERVFAIL answer to
294 their client after receiving and validating an unsupported NSEC3
295 parameter from the authoritative server(s) SHOULD return an Extended
296 DNS Error (EDE) [RFC8914] EDNS0 option of value 27. Validating
297 resolvers that choose to ignore a response with an unsupported
298 iteration count (and that do not validate the signature) MUST NOT
299 return this EDE option.
300
301 Note that this specification updates [RFC5155] by significantly
302 decreasing the requirements originally specified in Section 10.3 of
303 [RFC5155]. See the Security Considerations (Section 4) for arguments
304 on how to handle responses with non-zero iteration count.
305
306 3.3. Recommendation for Primary and Secondary Relationships
307
308 Primary and secondary authoritative servers for a zone that are not
309 being run by the same operational staff and/or using the same
310 software and configuration must take into account the potential
311 differences in NSEC3 iteration support.
312
313 Operators of secondary services should advertise the parameter limits
314 that their servers support. Correspondingly, operators of primary
315 servers need to ensure that their secondaries support the NSEC3
316 parameters they expect to use in their zones. To ensure reliability,
317 after primaries change their iteration counts, they should query
318 their secondaries with known nonexistent labels to verify the
319 secondary servers are responding as expected.
320
321 4. Security Considerations
322
323 This entire document discusses security considerations with various
324 parameter selections of NSEC3 and NSEC3PARAM fields.
325
326 The point where a validating resolver returns insecure versus the
327 point where it returns SERVFAIL must be considered carefully.
328 Specifically, when a validating resolver treats a zone as insecure
329 above a particular value (say 100) and returns SERVFAIL above a
330 higher point (say 500), it leaves the zone subject to attacker-in-
331 the-middle attacks as if it were unsigned between these values.
332 Thus, validating resolver operators and software implementers SHOULD
333 set the point above which a zone is treated as insecure for certain
334 values of NSEC3 iterations to the same as the point where a
335 validating resolver begins returning SERVFAIL.
336
337 5. Operational Considerations
338
339 This entire document discusses operational considerations with
340 various parameter selections of NSEC3 and NSEC3PARAM fields.
341
342 6. IANA Considerations
343
344 IANA has allocated the following code in the First Come First Served
345 range [RFC8126] of the "Extended DNS Error Codes" registry within the
346 "Domain Name System (DNS) Parameters" registry:
347
348 INFO-CODE: 27
349 Purpose: Unsupported NSEC3 iterations value
350 Reference: RFC 9276
351
352 7. References
353
354 7.1. Normative References
355
356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
357 Requirement Levels", BCP 14, RFC 2119,
358 DOI 10.17487/RFC2119, March 1997,
359 <https://www.rfc-editor.org/info/rfc2119>.
360
361 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
362 Rose, "Protocol Modifications for the DNS Security
363 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
364 <https://www.rfc-editor.org/info/rfc4035>.
365
366 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
367 and DNSSEC On-line Signing", RFC 4470,
368 DOI 10.17487/RFC4470, April 2006,
369 <https://www.rfc-editor.org/info/rfc4470>.
370
371 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
372 Security (DNSSEC) Hashed Authenticated Denial of
373 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
374 <https://www.rfc-editor.org/info/rfc5155>.
375
376 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
377 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
378 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
379
380 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
381 Lawrence, "Extended DNS Errors", RFC 8914,
382 DOI 10.17487/RFC8914, October 2020,
383 <https://www.rfc-editor.org/info/rfc8914>.
384
385 7.2. Informative References
386
387 [GPUNSEC3] Wander, M., Schwittmann, L., Boelmann, C., and T. Weis,
388 "GPU-Based NSEC3 Hash Breaking", DOI 10.1109/NCA.2014.27,
389 August 2014, <https://doi.org/10.1109/NCA.2014.27>.
390
391 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
392 Writing an IANA Considerations Section in RFCs", BCP 26,
393 RFC 8126, DOI 10.17487/RFC8126, June 2017,
394 <https://www.rfc-editor.org/info/rfc8126>.
395
396 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
397 Requirements and Usage Guidance for DNSSEC", RFC 8624,
398 DOI 10.17487/RFC8624, June 2019,
399 <https://www.rfc-editor.org/info/rfc8624>.
400
401 [ZONEENUM] Wang, Z., Xiao, L., and R. Wang, "An efficient DNSSEC zone
402 enumeration algorithm", DOI 10.2495/MIIT130591, April
403 2014, <https://doi.org/10.2495/MIIT130591>.
404
405 Appendix A. Deployment Measurements at Time of Publication
406
407 At the time of publication, setting an upper limit of 100 iterations
408 for treating a zone as insecure is interoperable without significant
409 problems, but at the same time still enables CPU-exhausting DoS
410 attacks.
411
412 At the time of publication, returning SERVFAIL beyond 500 iterations
413 appears to be interoperable without significant problems.
414
415 Appendix B. Computational Burdens of Processing NSEC3 Iterations
416
417 The queries per second (QPS) of authoritative servers will decrease
418 due to computational overhead when processing DNS requests for zones
419 containing higher NSEC3 iteration counts. The table below shows the
420 drop in QPS for various iteration counts.
421
422 +============+=============================+
423 | Iterations | QPS [% of 0 Iterations QPS] |
424 +============+=============================+
425 | 0 | 100% |
426 +------------+-----------------------------+
427 | 10 | 89% |
428 +------------+-----------------------------+
429 | 20 | 82% |
430 +------------+-----------------------------+
431 | 50 | 64% |
432 +------------+-----------------------------+
433 | 100 | 47% |
434 +------------+-----------------------------+
435 | 150 | 38% |
436 +------------+-----------------------------+
437
438 Table 1: Drop in QPS for Various
439 Iteration Counts
440
441 Acknowledgments
442
443 The authors would like to thank the participants in the dns-
444 operations discussion, which took place on mattermost hosted by DNS-
445 OARC.
446
447 Additionally, the following people contributed text or review
448 comments to this document:
449
450 * Vladimir Cunat
451
452 * Tony Finch
453
454 * Paul Hoffman
455
456 * Warren Kumari
457
458 * Alexander Mayrhofer
459
460 * Matthijs Mekking
461
462 * Florian Obser
463
464 * Petr Spacek
465
466 * Paul Vixie
467
468 * Tim Wicinski
469
470 Authors' Addresses
471
472 Wes Hardaker
473 USC/ISI
474 Email: ietf@hardakers.net
475
476
477 Viktor Dukhovni
478 Bloomberg, L.P.
479 Email: ietf-dane@dukhovni.org
480
Smaller zones, or large but relatively static zones, are encouraged to not use the opt-opt flag and to take advantage of DNSSEC's authenticated denial of existence.
Smaller zones, or large but relatively static zones, are encouraged to not use the opt-out flag and to take advantage of DNSSEC's authenticated denial of existence.
There is a typo, "opt-opt" should be "opt-out".