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                                                            
    9                  Guidance for NSEC3 Parameter Settings                     
   11 Abstract                                                                   
   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.                    
   21 Status of This Memo                                                        
   23    This memo documents an Internet Best Current Practice.                  
   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.                             
   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.                                
   35 Copyright Notice                                                           
   37    Copyright (c) 2022 IETF Trust and the persons identified as the         
   38    document authors.  All rights reserved.                                 
   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.                                             
   50 Table of Contents                                                          
   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                                                      
   74 1.  Introduction                                                           
   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).                                                   
   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.                                        
   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.                                                   
  101 1.1.  Requirements Notation                                                
  103    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  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.                                                
  109 2.  NSEC3 Parameter Value Discussions                                      
  111    The following sections describe the background of the parameters for    
  112    the NSEC3 and NSEC3PARAM RRTYPEs.                                       
  114 2.1.  Algorithms                                                           
  116    The algorithm field is not discussed by this document.  Readers are     
  117    encouraged to read [RFC8624] for guidance about DNSSEC algorithm        
  118    usage.                                                                  

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                                                                
  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.                                                              
  138 2.3.  Iterations                                                           
  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.         
  146    Note that [RFC5155] describes the Iterations field as follows           
  148    |  The Iterations field defines the number of additional times the      
  149    |  hash function has been performed.                                    
  151    This means that an NSEC3 record with an Iterations field of 0           
  152    actually requires one hash iteration.                                   
  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.   
  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.                   
  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].                                                  
  178 2.4.  Salt                                                                 
  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.                
  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.     
  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.                  
  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.                           
  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.                                             
  217 3.  Recommendations for Deploying and Validating NSEC3 Records             
  219    The following subsections describe recommendations for the different    
  220    operating realms within the DNS.                                        
  222 3.1.  Best Practice for Zone Publishers                                    
  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.                    
  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.        
  239    In short, for all zones, the recommended NSEC3 parameters are as        
  240    shown below:                                                            
  242    ; SHA-1, no extra iterations, empty salt:                               
  243    ;                                                                       
  244    bcp.example. IN NSEC3PARAM 1 0 0 -                                      
  246    For small zones, the use of opt-out-based NSEC3 records is NOT          
  247    RECOMMENDED.                                                            
  249    For very large and sparsely signed zones, where the majority of the     
  250    records are insecure delegations, opt-out MAY be used.                  
  252    Operators SHOULD NOT use a salt by indicating a zero-length salt        
  253    value instead (represented as a "-" in the presentation format).        
  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.                    
  261 3.2.  Recommendation for Validating Resolvers                              
  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.                                                                 
  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]).                                             
  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.                                    
  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.                                                 
  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.               
  306 3.3.  Recommendation for Primary and Secondary Relationships               
  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.                                 
  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.                           
  321 4.  Security Considerations                                                
  323    This entire document discusses security considerations with various     
  324    parameter selections of NSEC3 and NSEC3PARAM fields.                    
  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.                          
  337 5.  Operational Considerations                                             
  339    This entire document discusses operational considerations with          
  340    various parameter selections of NSEC3 and NSEC3PARAM fields.            
  342 6.  IANA Considerations                                                    
  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:                         
  348    INFO-CODE:  27                                                          
  349    Purpose:  Unsupported NSEC3 iterations value                            
  350    Reference:  RFC 9276                                                    
  352 7.  References                                                             
  354 7.1.  Normative References                                                 
  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>.                   
  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>.                   
  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>.                   
  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>.                   
  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>.         
  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>.                   
  385 7.2.  Informative References                                               
  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>.          
  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>.                   
  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>.                   
  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>.                  
  405 Appendix A.  Deployment Measurements at Time of Publication                
  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.                                                                
  412    At the time of publication, returning SERVFAIL beyond 500 iterations    
  413    appears to be interoperable without significant problems.               
  415 Appendix B.  Computational Burdens of Processing NSEC3 Iterations          
  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.                               
  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                +------------+-----------------------------+                
  438                      Table 1: Drop in QPS for Various                      
  439                              Iteration Counts                              
  441 Acknowledgments                                                            
  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.                                                                   
  447    Additionally, the following people contributed text or review           
  448    comments to this document:                                              
  450    *  Vladimir Cunat                                                       
  452    *  Tony Finch                                                           
  454    *  Paul Hoffman                                                         
  456    *  Warren Kumari                                                        
  458    *  Alexander Mayrhofer                                                  
  460    *  Matthijs Mekking                                                     
  462    *  Florian Obser                                                        
  464    *  Petr Spacek                                                          
  466    *  Paul Vixie                                                           
  468    *  Tim Wicinski                                                         
  470 Authors' Addresses                                                         
  472    Wes Hardaker                                                            
  473    USC/ISI                                                                 
  474    Email: ietf@hardakers.net                                               
  477    Viktor Dukhovni                                                         
  478    Bloomberg, L.P.                                                         
  479    Email: ietf-dane@dukhovni.org                                           
section-2.2 Stefan Ubbink(Editorial Erratum #7104) [Verified]
based on outdated version
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

It should say:
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

There is a typo, "opt-opt" should be "opt-out".