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