1 Internet Engineering Task Force (IETF)                        P. Hoffman   
    2 Request for Comments: 9364                                         ICANN   
    3 BCP: 237                                                   February 2023   
    4 Category: Best Current Practice                                            
    5 ISSN: 2070-1721                                                            
    8                     DNS Security Extensions (DNSSEC)                       
   10 Abstract                                                                   
   12    This document describes the DNS Security Extensions (commonly called    
   13    "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as   
   14    a handful of others.  One purpose is to introduce all of the RFCs in    
   15    one place so that the reader can understand the many aspects of         
   16    DNSSEC.  This document does not update any of those RFCs.  A second     
   17    purpose is to state that using DNSSEC for origin authentication of      
   18    DNS data is the best current practice.  A third purpose is to provide   
   19    a single reference for other documents that want to refer to DNSSEC.    
   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/rfc9364.                                
   35 Copyright Notice                                                           
   37    Copyright (c) 2023 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.  DNSSEC as a Best Current Practice                               
   54      1.2.  Implementing DNSSEC                                             
   55    2.  DNSSEC Core Documents                                               
   56      2.1.  Addition to the DNSSEC Core                                     
   57    3.  Additional Cryptographic Algorithms and DNSSEC                      
   58    4.  Extensions to DNSSEC                                                
   59    5.  Additional Documents of Interest                                    
   60    6.  IANA Considerations                                                 
   61    7.  Security Considerations                                             
   62    8.  References                                                          
   63      8.1.  Normative References                                            
   64      8.2.  Informative References                                          
   65    Acknowledgements                                                        
   66    Author's Address                                                        
   68 1.  Introduction                                                           
   70    The core specification for what we know as DNSSEC (the combination of   
   71    [RFC4033], [RFC4034], and [RFC4035]) describes a set of protocols       
   72    that provide origin authentication of DNS data.  [RFC6840] updates      
   73    and extends those core RFCs but does not fundamentally change the way   
   74    that DNSSEC works.                                                      
   76    This document lists RFCs that should be considered by someone           
   77    creating an implementation of, or someone deploying, DNSSEC as it is    
   78    currently standardized.  Although an effort was made to be thorough,    
   79    the reader should not assume this list is comprehensive.  It uses       
   80    terminology from those documents without defining that terminology.     
   81    It also points to the relevant IANA registry groups that relate to      
   82    DNSSEC.  It does not, however, point to standards that rely on zones    
   83    needing to be signed by DNSSEC, such as DNS-Based Authentication of     
   84    Named Entities (DANE) [RFC6698].                                        
   86 1.1.  DNSSEC as a Best Current Practice                                    
   88    Using the DNSSEC set of protocols is the best current practice for      
   89    adding origin authentication of DNS data.  To date, no Standards        
   90    Track RFCs offer any other method for such origin authentication of     
   91    data in the DNS.                                                        
   93    More than 15 years after the DNSSEC specification was published, it     
   94    is still not widely deployed.  Recent estimates are that fewer than     
   95    10% of the domain names used for websites are signed, and only around   
   96    a third of queries to recursive resolvers are validated.  However,      
   97    this low level of deployment does not affect whether using DNSSEC is    
   98    a best current practice; it just indicates that the value of            
   99    deploying DNSSEC is often considered lower than the cost.               
  100    Nonetheless, the significant deployment of DNSSEC beneath some top-     
  101    level domains (TLDs) and the near-universal deployment of DNSSEC for    
  102    the TLDs in the DNS root zone demonstrate that DNSSEC is applicable     
  103    for implementation by both ordinary and highly sophisticated domain     
  104    owners.                                                                 
  106 1.2.  Implementing DNSSEC                                                  
  108    Developers of validating resolvers and authoritative servers, as well   
  109    as operators of validating resolvers and authoritative servers, need    
  110    to know the parts of the DNSSEC protocol that would affect them.        
  111    They should read the DNSSEC core documents and probably at least be     
  112    familiar with the extensions.  Developers will probably need to be      
  113    very familiar with the algorithm documents as well.                     
  115    As a side note, some of the DNSSEC-related RFCs have significant        
  116    errata, so reading the RFCs should also include looking for the         
  117    related errata.                                                         
  119 2.  DNSSEC Core Documents                                                  
  121    What we refer to as "DNSSEC" is the third iteration of the DNSSEC       
  122    specification; [RFC2065] was the first, and [RFC2535] was the second.   
  123    Earlier iterations have not been deployed on a significant scale.       
  124    Throughout this document, "DNSSEC" means the protocol initially         
  125    defined in [RFC4033], [RFC4034], and [RFC4035].                         
  127    The three initial core documents generally cover different topics:      
  129    *  [RFC4033] is an overview of DNSSEC, including how it might change    
  130       the resolution of DNS queries.                                       
  132    *  [RFC4034] specifies the DNS resource records used in DNSSEC.  It     
  133       obsoletes many RFCs about earlier versions of DNSSEC.                
  135    *  [RFC4035] covers the modifications to the DNS protocol incurred by   
  136       DNSSEC.  These include signing zones, serving signed zones,          
  137       resolving in light of DNSSEC, and authenticating DNSSEC-signed       
  138       data.                                                                
  140    At the time this set of core documents was published, someone could     
  141    create a DNSSEC implementation of signing software, of a DNSSEC-aware   
  142    authoritative server, and/or of a DNSSEC-aware recursive resolver       
  143    from the three core documents, plus a few older RFCs specifying the     
  144    cryptography used.  Those two older documents are the following:        
  146    *  [RFC2536] defines how to use the DSA signature algorithm (although   
  147       it refers to other documents for the details).  DSA was thinly       
  148       implemented and can safely be ignored by DNSSEC implementations.     
  150    *  [RFC3110] defines how to use the RSA signature algorithm (although   
  151       refers to other documents for the details).  RSA is still among      
  152       the most popular signing algorithms for DNSSEC.                      
  154    It is important to note that later RFCs update the core documents.      
  155    As just one example, [RFC9077] changes how TTL values are calculated    
  156    in DNSSEC processing.                                                   
  158 2.1.  Addition to the DNSSEC Core                                          
  160    As with any major protocol, developers and operators discovered         
  161    issues with the original core documents over the years.  [RFC6840] is   
  162    an omnibus update to the original core documents and thus itself has    
  163    become a core document.  In addition to covering new requirements       
  164    from new DNSSEC RFCs, it describes many important security and          
  165    interoperability issues that arose during the deployment of the         
  166    initial specifications, particularly after the DNS root was signed in   
  167    2010.  It also lists some errors in the examples of the core            
  168    specifications.                                                         
  170    [RFC6840] brings a few additions into the core of DNSSEC.  It makes     
  171    NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is.  It also makes     
  172    the SHA-256 and SHA-512 hash functions defined in [RFC4509] and         
  173    [RFC5702] part of the core.                                             
  175 3.  Additional Cryptographic Algorithms and DNSSEC                         
  177    Current cryptographic algorithms typically weaken over time as          
  178    computing power improves and new cryptoanalysis emerges.  Two new       
  179    signing algorithms have been adopted by the DNSSEC community:           
  180    Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605] and        
  181    Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8080].  ECDSA     
  182    and EdDSA have become very popular signing algorithms in recent         
  183    years.  The GOST signing algorithm [GOST-SIGN] was also adopted but     
  184    has seen very limited use, likely because it is a national algorithm    
  185    specific to a very small number of countries.                           
  187    Implementation developers who want to know which algorithms to          
  188    implement in DNSSEC software should refer to [RFC8624].  Note that      
  189    this specification is only about what algorithms should and should      
  190    not be included in implementations, i.e., it is not advice about        
  191    which algorithms zone operators should or should not use for signing,   
  192    nor which algorithms recursive resolver operators should or should      
  193    not use for validation.                                                 
  195 4.  Extensions to DNSSEC                                                   
  197    The DNSSEC community has extended the DNSSEC core and the               
  198    cryptographic algorithms, both in terms of describing good              
  199    operational practices and in new protocols.  Some of the RFCs that      
  200    describe these extensions include the following:                        
  202    *  [RFC5011] describes a method to help resolvers update their DNSSEC   
  203       trust anchors in an automated fashion.  This method was used in      
  204       2018 to update the DNS root trust anchor.                            
  206    *  [RFC6781] is a compendium of operational practices that may not be   
  207       obvious from reading just the core specifications.                   
  209    *  [RFC7344] describes using the CDS and CDNSKEY resource records to    
  210       help automate the maintenance of DS records in the parents of        
  211       signed zones.                                                        
  213    *  [RFC8078] extends [RFC7344] by showing how to do initial setup of    
  214       trusted relationships between signed parent and child zones.         
  216    *  [RFC8198] describes how a validating resolver can emit fewer         
  217       queries in signed zones that use NSEC and NSEC3 for negative         
  218       caching.                                                             
  220    *  [RFC9077] updates [RFC8198] with respect to the TTL fields in        
  221       signed records.                                                      
  223 5.  Additional Documents of Interest                                       
  225    The documents listed above constitute the core of DNSSEC, the           
  226    additional cryptographic algorithms, and the major extensions to        
  227    DNSSEC.  This section lists some additional documents that someone      
  228    interested in implementing or operating DNSSEC might find of value:     
  230    *  [RFC4470] "describes how to construct DNSSEC NSEC resource records   
  231       that cover a smaller range of names than called for by [RFC4034].    
  232       By generating and signing these records on demand, authoritative     
  233       name servers can effectively stop the disclosure of zone contents    
  234       otherwise made possible by walking the chain of NSEC records in a    
  235       signed zone".                                                        
  237    *  [RFC6975] "specifies a way for validating end-system resolvers to    
  238       signal to a server which digital signature and hash algorithms       
  239       they support".                                                       
  241    *  [RFC7129] "provides additional background commentary and some        
  242       context for the NSEC and NSEC3 mechanisms used by DNSSEC to          
  243       provide authenticated denial-of-existence responses".  This          
  244       background is particularly important for understanding NSEC and      
  245       NSEC3 usage.                                                         
  247    *  [RFC7583] "describes the issues surrounding the timing of events     
  248       in the rolling of a key in a DNSSEC-secured zone".                   
  250    *  [RFC7646] "defines Negative Trust Anchors (NTAs), which can be       
  251       used to mitigate DNSSEC validation failures by disabling DNSSEC      
  252       validation at specified domains".                                    
  254    *  [RFC7958] "describes the format and publication mechanisms IANA      
  255       has used to distribute the DNSSEC trust anchors".                    
  257    *  [RFC8027] "describes problems that a Validating DNS resolver,        
  258       stub-resolver, or application might run into within a non-           
  259       compliant infrastructure".                                           
  261    *  [RFC8145] "specifies two different ways for validating resolvers     
  262       to signal to a server which keys are referenced in their chain of    
  263       trust".                                                              
  265    *  [RFC8499] contains lists of terminology used when talking about      
  266       DNS; Sections 10 and 11 cover DNSSEC.                                
  268    *  [RFC8509] "specifies a mechanism that will allow an end user and     
  269       third parties to determine the trusted key state for the root key    
  270       of the resolvers that handle that user's DNS queries".               
  272    *  [RFC8901] "presents deployment models that accommodate this          
  273       scenario [when each DNS provider independently signs zone data       
  274       with their own keys] and describes these key-management              
  275       requirements".                                                       
  277    *  [RFC9276] "provides guidance on setting NSEC3 parameters based on    
  278       recent operational deployment experience".                           
  280    There will certainly be other RFCs related to DNSSEC that are           
  281    published after this one.                                               
  283 6.  IANA Considerations                                                    
  285    IANA already has three registry groups that relate to DNSSEC:           
  287    *  DNSSEC algorithm numbers (https://www.iana.org/assignments/dns-      
  288       sec-alg-numbers)                                                     
  290    *  DNSSEC NSEC3 parameters (https://www.iana.org/assignments/dnssec-    
  291       nsec3-parameters)                                                    
  293    *  DNSSEC DS RRtype digest algorithms                                   
  294       (https://www.iana.org/assignments/ds-rr-types)                       
  296    The rules for the DNSSEC algorithm registry were set in the core RFCs   
  297    and updated by [RFC6014], [RFC6725], and [RFC9157].                     
  299    This document does not update or create any registry groups or          
  300    registries.                                                             
  302 7.  Security Considerations                                                
  304    All of the security considerations from all of the RFCs referenced in   
  305    this document apply here.                                               
  307 8.  References                                                             
  309 8.1.  Normative References                                                 
  311    [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the        
  312               Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110,   
  313               May 2001, <https://www.rfc-editor.org/info/rfc3110>.         
  315    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  316               Rose, "DNS Security Introduction and Requirements",          
  317               RFC 4033, DOI 10.17487/RFC4033, March 2005,                  
  318               <https://www.rfc-editor.org/info/rfc4033>.                   
  320    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  321               Rose, "Resource Records for the DNS Security Extensions",    
  322               RFC 4034, DOI 10.17487/RFC4034, March 2005,                  
  323               <https://www.rfc-editor.org/info/rfc4034>.                   
  325    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  326               Rose, "Protocol Modifications for the DNS Security           
  327               Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,     
  328               <https://www.rfc-editor.org/info/rfc4035>.                   
  330    [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer    
  331               (DS) Resource Records (RRs)", RFC 4509,                      
  332               DOI 10.17487/RFC4509, May 2006,                              
  333               <https://www.rfc-editor.org/info/rfc4509>.                   
  335    [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS      
  336               Security (DNSSEC) Hashed Authenticated Denial of             
  337               Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,      
  338               <https://www.rfc-editor.org/info/rfc5155>.                   
  340    [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY      
  341               and RRSIG Resource Records for DNSSEC", RFC 5702,            
  342               DOI 10.17487/RFC5702, October 2009,                          
  343               <https://www.rfc-editor.org/info/rfc5702>.                   
  345    [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and      
  346               Implementation Notes for DNS Security (DNSSEC)", RFC 6840,   
  347               DOI 10.17487/RFC6840, February 2013,                         
  348               <https://www.rfc-editor.org/info/rfc6840>.                   
  350 8.2.  Informative References                                               
  352    [GOST-SIGN]                                                             
  353               Belyavsky, D., Dolmatov, V., Ed., and B. Makarenko, Ed.,     
  354               "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG   
  355               Resource Records for DNSSEC", Work in Progress, Internet-    
  356               Draft, draft-ietf-dnsop-rfc5933-bis-13, 30 November 2022,    
  357               <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-     
  358               rfc5933-bis-13>.                                             
  360    [RFC2065]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System         
  361               Security Extensions", RFC 2065, DOI 10.17487/RFC2065,        
  362               January 1997, <https://www.rfc-editor.org/info/rfc2065>.     
  364    [RFC2535]  Eastlake 3rd, D., "Domain Name System Security               
  365               Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,     
  366               <https://www.rfc-editor.org/info/rfc2535>.                   
  368    [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name      
  369               System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999,   
  370               <https://www.rfc-editor.org/info/rfc2536>.                   
  372    [RFC4470]  Weiler, S. and J. Ihren, "Minimally Covering NSEC Records    
  373               and DNSSEC On-line Signing", RFC 4470,                       
  374               DOI 10.17487/RFC4470, April 2006,                            
  375               <https://www.rfc-editor.org/info/rfc4470>.                   
  377    [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)     
  378               Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,      
  379               September 2007, <https://www.rfc-editor.org/info/rfc5011>.   
  381    [RFC6014]  Hoffman, P., "Cryptographic Algorithm Identifier             
  382               Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,      
  383               November 2010, <https://www.rfc-editor.org/info/rfc6014>.    
  385    [RFC6605]  Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital   
  386               Signature Algorithm (DSA) for DNSSEC", RFC 6605,             
  387               DOI 10.17487/RFC6605, April 2012,                            
  388               <https://www.rfc-editor.org/info/rfc6605>.                   
  390    [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication   
  391               of Named Entities (DANE) Transport Layer Security (TLS)      
  392               Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August      
  393               2012, <https://www.rfc-editor.org/info/rfc6698>.             
  395    [RFC6725]  Rose, S., "DNS Security (DNSSEC) DNSKEY Algorithm IANA       
  396               Registry Updates", RFC 6725, DOI 10.17487/RFC6725, August    
  397               2012, <https://www.rfc-editor.org/info/rfc6725>.             
  399    [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC             
  400               Operational Practices, Version 2", RFC 6781,                 
  401               DOI 10.17487/RFC6781, December 2012,                         
  402               <https://www.rfc-editor.org/info/rfc6781>.                   
  404    [RFC6975]  Crocker, S. and S. Rose, "Signaling Cryptographic            
  405               Algorithm Understanding in DNS Security Extensions           
  406               (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,        
  407               <https://www.rfc-editor.org/info/rfc6975>.                   
  409    [RFC7129]  Gieben, R. and W. Mekking, "Authenticated Denial of          
  410               Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,       
  411               February 2014, <https://www.rfc-editor.org/info/rfc7129>.    
  413    [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating     
  414               DNSSEC Delegation Trust Maintenance", RFC 7344,              
  415               DOI 10.17487/RFC7344, September 2014,                        
  416               <https://www.rfc-editor.org/info/rfc7344>.                   
  418    [RFC7583]  Morris, S., Ihren, J., Dickinson, J., and W. Mekking,        
  419               "DNSSEC Key Rollover Timing Considerations", RFC 7583,       
  420               DOI 10.17487/RFC7583, October 2015,                          
  421               <https://www.rfc-editor.org/info/rfc7583>.                   
  423    [RFC7646]  Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,      
  424               and R. Weber, "Definition and Use of DNSSEC Negative Trust   
  425               Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,    
  426               <https://www.rfc-editor.org/info/rfc7646>.                   
  428    [RFC7958]  Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,         
  429               "DNSSEC Trust Anchor Publication for the Root Zone",         
  430               RFC 7958, DOI 10.17487/RFC7958, August 2016,                 
  431               <https://www.rfc-editor.org/info/rfc7958>.                   
  433    [RFC8027]  Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,          
  434               "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,             
  435               DOI 10.17487/RFC8027, November 2016,                         
  436               <https://www.rfc-editor.org/info/rfc8027>.                   
  438    [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from    
  439               the Parent via CDS/CDNSKEY", RFC 8078,                       
  440               DOI 10.17487/RFC8078, March 2017,                            
  441               <https://www.rfc-editor.org/info/rfc8078>.                   
  443    [RFC8080]  Sury, O. and R. Edmonds, "Edwards-Curve Digital Security     
  444               Algorithm (EdDSA) for DNSSEC", RFC 8080,                     
  445               DOI 10.17487/RFC8080, February 2017,                         
  446               <https://www.rfc-editor.org/info/rfc8080>.                   
  448    [RFC8145]  Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust    
  449               Anchor Knowledge in DNS Security Extensions (DNSSEC)",       
  450               RFC 8145, DOI 10.17487/RFC8145, April 2017,                  
  451               <https://www.rfc-editor.org/info/rfc8145>.                   
  453    [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of    
  454               DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,     
  455               July 2017, <https://www.rfc-editor.org/info/rfc8198>.        
  457    [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS             
  458               Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,       
  459               January 2019, <https://www.rfc-editor.org/info/rfc8499>.     
  461    [RFC8509]  Huston, G., Damas, J., and W. Kumari, "A Root Key Trust      
  462               Anchor Sentinel for DNSSEC", RFC 8509,                       
  463               DOI 10.17487/RFC8509, December 2018,                         
  464               <https://www.rfc-editor.org/info/rfc8509>.                   
  466    [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation           
  467               Requirements and Usage Guidance for DNSSEC", RFC 8624,       
  468               DOI 10.17487/RFC8624, June 2019,                             
  469               <https://www.rfc-editor.org/info/rfc8624>.                   
  471    [RFC8901]  Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.       
  472               Blacka, "Multi-Signer DNSSEC Models", RFC 8901,              
  473               DOI 10.17487/RFC8901, September 2020,                        
  474               <https://www.rfc-editor.org/info/rfc8901>.                   
  476    [RFC9077]  van Dijk, P., "NSEC and NSEC3: TTLs and Aggressive Use",     
  477               RFC 9077, DOI 10.17487/RFC9077, July 2021,                   
  478               <https://www.rfc-editor.org/info/rfc9077>.                   
  480    [RFC9157]  Hoffman, P., "Revised IANA Considerations for DNSSEC",       
  481               RFC 9157, DOI 10.17487/RFC9157, December 2021,               
  482               <https://www.rfc-editor.org/info/rfc9157>.                   
  484    [RFC9276]  Hardaker, W. and V. Dukhovni, "Guidance for NSEC3            
  485               Parameter Settings", BCP 236, RFC 9276,                      
  486               DOI 10.17487/RFC9276, August 2022,                           
  487               <https://www.rfc-editor.org/info/rfc9276>.                   
  489 Acknowledgements                                                           
  491    The DNS world owes a depth of gratitude to the authors and other        
  492    contributors to the core DNSSEC documents and to the notable DNSSEC     
  493    extensions.                                                             
  495    In addition, the following people made significant contributions to     
  496    early draft versions of this document: Ben Schwartz and Duane           
  497    Wessels.                                                                
  499 Author's Address                                                           
  501    Paul Hoffman                                                            
  502    ICANN                                                                   
  503    Email: paul.hoffman@icann.org                                           

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.