1 Internet Engineering Task Force (IETF)                        P. Wouters   
    2 Request for Comments: 8624                                       Red Hat   
    3 Obsoletes: 6944                                                  O. Sury   
    4 Category: Standards Track                    Internet Systems Consortium   
    5 ISSN: 2070-1721                                                June 2019   
    6                                                                            
    7                                                                            
    8   Algorithm Implementation Requirements and Usage Guidance for DNSSEC      
    9                                                                            
   10 Abstract                                                                   
   11                                                                            
   12    The DNSSEC protocol makes use of various cryptographic algorithms in    
   13    order to provide authentication of DNS data and proof of                
   14    nonexistence.  To ensure interoperability between DNS resolvers and     
   15    DNS authoritative servers, it is necessary to specify a set of          
   16    algorithm implementation requirements and usage guidelines to ensure    
   17    that there is at least one algorithm that all implementations           
   18    support.  This document defines the current algorithm implementation    
   19    requirements and usage guidance for DNSSEC.  This document obsoletes    
   20    RFC 6944.                                                               
   21                                                                            
   22 Status of This Memo                                                        
   23                                                                            
   24    This is an Internet Standards Track document.                           
   25                                                                            
   26    This document is a product of the Internet Engineering Task Force       
   27    (IETF).  It represents the consensus of the IETF community.  It has     
   28    received public review and has been approved for publication by the     
   29    Internet Engineering Steering Group (IESG).  Further information on     
   30    Internet Standards is available in Section 2 of RFC 7841.               
   31                                                                            
   32    Information about the current status of this document, any errata,      
   33    and how to provide feedback on it may be obtained at                    
   34    https://www.rfc-editor.org/info/rfc8624.                                
   35                                                                            
   36                                                                            
   37                                                                            
   38                                                                            
   39                                                                            
   40                                                                            
   41                                                                            
   42                                                                            
   43                                                                            
   44                                                                            
   45                                                                            
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Wouters & Sury               Standards Track                    [Page 1]   

   53 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
   54                                                                            
   55                                                                            
   56 Copyright Notice                                                           
   57                                                                            
   58    Copyright (c) 2019 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   60                                                                            
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (https://trustee.ietf.org/license-info) in effect on the date of        
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.  Code Components extracted from this document must    
   67    include Simplified BSD License text as described in Section 4.e of      
   68    the Trust Legal Provisions and are provided without warranty as         
   69    described in the Simplified BSD License.                                
   70                                                                            
   71 Table of Contents                                                          
   72                                                                            
   73    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   
   74      1.1.  Updating Algorithm Implementation Requirements and Usage        
   75            Guidance  . . . . . . . . . . . . . . . . . . . . . . . .   3   
   76      1.2.  Updating Algorithm Requirement Levels . . . . . . . . . .   3   
   77      1.3.  Document Audience . . . . . . . . . . . . . . . . . . . .   4   
   78    2.  Conventions Used in This Document . . . . . . . . . . . . . .   4   
   79    3.  Algorithm Selection . . . . . . . . . . . . . . . . . . . . .   5   
   80      3.1.  DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . .   5   
   81      3.2.  DNSKEY Algorithm Recommendation . . . . . . . . . . . . .   6   
   82      3.3.  DS and CDS Algorithms . . . . . . . . . . . . . . . . . .   7   
   83      3.4.  DS and CDS Algorithm Recommendation . . . . . . . . . . .   7   
   84    4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8   
   85    5.  Operational Considerations  . . . . . . . . . . . . . . . . .   8   
   86    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8   
   87    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9   
   88      7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9   
   89      7.2.  Informative References  . . . . . . . . . . . . . . . . .  10   
   90    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11   
   91    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11   
   92                                                                            
   93                                                                            
   94                                                                            
   95                                                                            
   96                                                                            
   97                                                                            
   98                                                                            
   99                                                                            
  100                                                                            
  101                                                                            
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Wouters & Sury               Standards Track                    [Page 2]   

  108 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  109                                                                            
  110                                                                            
  111 1.  Introduction                                                           
  112                                                                            
  113    The DNSSEC signing algorithms are defined by various RFCs, including    
  114    [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], and [RFC8080].   
  115    DNSSEC is used to provide authentication of data.  To ensure            
  116    interoperability, a set of "mandatory-to-implement" DNSKEY algorithms   
  117    are defined.  This document obsoletes [RFC6944].                        
  118                                                                            
  119 1.1.  Updating Algorithm Implementation Requirements and Usage Guidance    
  120                                                                            
  121    The field of cryptography evolves continuously.  New, stronger          
  122    algorithms appear, and existing algorithms are found to be less         
  123    secure than originally thought.  Attacks previously thought to be       
  124    computationally infeasible become more accessible as the available      
  125    computational resources increase.  Therefore, algorithm                 
  126    implementation requirements and usage guidance need to be updated       
  127    from time to time to reflect the new reality.  The choices for          
  128    algorithms must be conservative to minimize the risk of algorithm       
  129    compromise.                                                             
  130                                                                            
  131 1.2.  Updating Algorithm Requirement Levels                                
  132                                                                            
  133    The mandatory-to-implement algorithm of tomorrow should already be      
  134    available in most implementations of DNSSEC by the time it is made      
  135    mandatory.  This document attempts to identify and introduce those      
  136    algorithms for future mandatory-to-implement status.  There is no       
  137    guarantee that algorithms in use today will become mandatory in the     
  138    future.  Published algorithms are continuously subjected to             
  139    cryptographic attack and may become too weak or even be completely      
  140    broken before this document is updated.                                 
  141                                                                            

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.

GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15

This RFC is implemented in BIND 9.18 (all versions).

RFC 8624 obsoleted RFC6944. That older RFC updated many RFCs, but those are not listed here because that sometimes happens in the RFC series.

RFC6944 updates:

  142    This document only provides recommendations with respect to             
  143    mandatory-to-implement algorithms or algorithms so weak that they       
  144    cannot be recommended.  Any algorithm listed in the [DNSKEY-IANA] and   
  145    [DS-IANA] registries that are not mentioned in this document MAY be     
  146    implemented.  For clarification and consistency, an algorithm will be   
  147    specified as MAY in this document only when it has been downgraded      
  148    from a MUST or a RECOMMENDED to a MAY.                                  
  149                                                                            
  150    Although this document's primary purpose is to update algorithm         
  151    recommendations to keep DNSSEC authentication secure over time, it      
  152    also aims to do so in such a way that DNSSEC implementations remain     
  153    interoperable.  DNSSEC interoperability is addressed by an              
  154    incremental introduction or deprecation of algorithms.                  
  155                                                                            
  156    [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and      
  157    SHOULD NOT equivalent to NOT RECOMMENDED.  The authors of this          
  158    document have chosen to use the terms RECOMMENDED and NOT               
  159                                                                            
  160                                                                            
  161                                                                            
  162 Wouters & Sury               Standards Track                    [Page 3]   

  163 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  164                                                                            
  165                                                                            
  166    RECOMMENDED, as this more clearly expresses the intent to               
  167    implementers.                                                           
  168                                                                            
  169    It is expected that deprecation of an algorithm will be performed       
  170    gradually in a series of updates to this document.  This provides       
  171    time for various implementations to update their implemented            
  172    algorithms while remaining interoperable.  Unless there are strong      
  173    security reasons, an algorithm is expected to be downgraded from MUST   
  174    to NOT RECOMMENDED or MAY, instead of to MUST NOT.  Similarly, an       
  175    algorithm that has not been mentioned as mandatory-to-implement is      
  176    expected to be introduced with a RECOMMENDED instead of a MUST.         
  177                                                                            
  178    Since the effect of using an unknown DNSKEY algorithm is that the       
  179    zone is treated as insecure, it is recommended that algorithms          
  180    downgraded to NOT RECOMMENDED or lower not be used by authoritative     
  181    nameservers and DNSSEC signers to create new DNSKEYs.  This will        
  182    allow for deprecated algorithms to become less and less common over     
  183    time.  Once an algorithm has reached a sufficiently low level of        
  184    deployment, it can be marked as MUST NOT so that recursive resolvers    
  185    can remove support for validating it.                                   
  186                                                                            
  187    Recursive nameservers are encouraged to retain support for all          
  188    algorithms not marked as MUST NOT.                                      
  189                                                                            
  190 1.3.  Document Audience                                                    
  191                                                                            
  192    The recommendations of this document mostly target DNSSEC               
  193    implementers, as implementations need to meet both high security        
  194    expectations as well as high interoperability between various vendors   
  195    and with different versions.  Interoperability requires a smooth        
  196    transition to more secure algorithms.  This perspective may differ      
  197    from that of a user who wishes to deploy and configure DNSSEC with      
  198    only the safest algorithm.  On the other hand, the comments and         
  199    recommendations in this document are also expected to be useful for     
  200    such users.                                                             
  201                                                                            
  202 2.  Conventions Used in This Document                                      
  203                                                                            
  204    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  205    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and    
  206    "OPTIONAL" in this document are to be interpreted as described in       
  207    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  208    capitals, as shown here.                                                
  209                                                                            
  210                                                                            
  211                                                                            
  212                                                                            
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Wouters & Sury               Standards Track                    [Page 4]   

  218 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  219                                                                            
  220                                                                            
  221 3.  Algorithm Selection                                                    
  222                                                                            
  223 3.1.  DNSKEY Algorithms                                                    
  224                                                                            
  225    The following table lists the implementation recommendations for        
  226    DNSKEY algorithms [DNSKEY-IANA].                                        
  227                                                                            
  228    +--------+--------------------+-----------------+-------------------+   
  229    | Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |   
  230    +--------+--------------------+-----------------+-------------------+   
  231    | 1      | RSAMD5             | MUST NOT        | MUST NOT          |   
  232    | 3      | DSA                | MUST NOT        | MUST NOT          |   
  233    | 5      | RSASHA1            | NOT RECOMMENDED | MUST              |   
  234    | 6      | DSA-NSEC3-SHA1     | MUST NOT        | MUST NOT          |   
  235    | 7      | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST              |   
  236    | 8      | RSASHA256          | MUST            | MUST              |   
  237    | 10     | RSASHA512          | NOT RECOMMENDED | MUST              |   
  238    | 12     | ECC-GOST           | MUST NOT        | MAY               |   
  239    | 13     | ECDSAP256SHA256    | MUST            | MUST              |   
  240    | 14     | ECDSAP384SHA384    | MAY             | RECOMMENDED       |   
  241    | 15     | ED25519            | RECOMMENDED     | RECOMMENDED       |   
  242    | 16     | ED448              | MAY             | RECOMMENDED       |   
  243    +--------+--------------------+-----------------+-------------------+   
  244                                                                            
  245    RSAMD5 is not widely deployed, and there is an industry-wide trend to   
  246    deprecate MD5 usage.                                                    
  247                                                                            
  248    RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although the        
  249    zones deploying it are recommended to switch to ECDSAP256SHA256 as      
  250    there is an industry-wide trend to move to elliptic curve               
  251    cryptography.  RSASHA1 does not support NSEC3.  RSASHA1-NSEC3-SHA1      
  252    can be used with or without NSEC3.                                      
  253                                                                            
  254    DSA and DSA-NSEC3-SHA1 are not widely deployed and are vulnerable to    
  255    private key compromise when generating signatures using a weak or       
  256    compromised random number generator.                                    
  257                                                                            
  258    RSASHA256 is widely used and considered strong.  It has been the        
  259    default algorithm for a number of years and is now slowly being         
  260    replaced with ECDSAP256SHA256 due to its shorter key and signature      
  261    size, resulting in smaller DNS packets.                                 
  262                                                                            
  263    RSASHA512 is NOT RECOMMENDED for DNSSEC signing because it has not      
  264    seen wide deployment, but there are some deployments; hence, DNSSEC     
  265    validation MUST implement RSASHA512 to ensure interoperability.         
  266    There is no significant difference in cryptographic strength between    
  267    RSASHA512 and RSASHA256; therefore, use of RSASHA512 is discouraged     
  268                                                                            
  269                                                                            
  270                                                                            
  271                                                                            
  272 Wouters & Sury               Standards Track                    [Page 5]   

  273 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  274                                                                            
  275                                                                            
  276    as it will only make deprecation of older algorithms harder.  People    
  277    who wish to use a cryptographically stronger algorithm should switch    
  278    to elliptic curve cryptography algorithms.                              
  279                                                                            
  280    ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012   
  281    in [RFC7091].  GOST R 34.10-2012 hasn't been standardized for use in    
  282    DNSSEC.                                                                 
  283                                                                            
  284    ECDSAP256SHA256 provides more cryptographic strength with a shorter     
  285    signature length than either RSASHA256 or RSASHA512.  ECDSAP256SHA256   
  286    has been widely deployed; therefore, it is now at MUST level for both   
  287    validation and signing.  It is RECOMMENDED to use the deterministic     
  288    digital signature generation procedure of the Elliptic Curve Digital    
  289    Signature Algorithm (ECDSA), specified in [RFC6979], when               
  290    implementing ECDSAP256SHA256 (and ECDSAP384SHA384).                     
  291                                                                            
  292    ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256 but       
  293    offers a modest security advantage over ECDSAP256SHA256 (192 bits of    
  294    strength versus 128 bits).  For most DNSSEC applications,               
  295    ECDSAP256SHA256 should be satisfactory and robust for the foreseeable   
  296    future and is therefore recommended for signing.  While it is           
  297    unlikely for a DNSSEC use case requiring 192-bit security strength to   
  298    arise, ECDSA384SHA384 is provided for such applications, and it MAY     
  299    be used for signing in these cases.                                     
  300                                                                            
  301    ED25519 and ED448 use the Edwards-curve Digital Security Algorithm      
  302    (EdDSA).  There are three main advantages of EdDSA: it does not         
  303    require the use of a unique random number for each signature, there     
  304    are no padding or truncation issues as with ECDSA, and it is more       
  305    resilient to side-channel attacks.  Furthermore, EdDSA cryptography     
  306    is less prone to implementation errors ([RFC8032], [RFC8080]).  It is   
  307    expected that ED25519 will become the future RECOMMENDED default        
  308    algorithm once there's enough support for this algorithm in the         
  309    deployed DNSSEC validators.                                             
  310                                                                            
  311 3.2.  DNSKEY Algorithm Recommendation                                      
  312                                                                            
  313    Due to the industry-wide trend towards elliptic curve cryptography,     
  314    ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new      
  315    DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade    
  316    to ECDSAP256SHA256.                                                     
  317                                                                            
  318                                                                            
  319                                                                            
  320                                                                            
  321                                                                            
  322                                                                            
  323                                                                            
  324                                                                            
  325                                                                            
  326                                                                            
  327 Wouters & Sury               Standards Track                    [Page 6]   

  328 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  329                                                                            
  330                                                                            
  331 3.3.  DS and CDS Algorithms                                                
  332                                                                            
  333    The following table lists the recommendations for Delegation Signer     
  334    Digest Algorithms [DS-IANA].  These recommendations also apply to the   
  335    Child Delegation Signer (CDS) RRTYPE as specified in [RFC7344].         
  336                                                                            
  337    +--------+-----------------+-------------------+-------------------+    
  338    | Number | Mnemonics       | DNSSEC Delegation | DNSSEC Validation |    
  339    +--------+-----------------+-------------------+-------------------+    
  340    | 0      | NULL (CDS only) | MUST NOT [*]      | MUST NOT [*]      |    
  341    | 1      | SHA-1           | MUST NOT          | MUST              |    
  342    | 2      | SHA-256         | MUST              | MUST              |    
  343    | 3      | GOST R 34.11-94 | MUST NOT          | MAY               |    
  344    | 4      | SHA-384         | MAY               | RECOMMENDED       |    
  345    +--------+-----------------+-------------------+-------------------+    
  346                                                                            
  347    [*] - This is a special type of CDS record signaling removal of DS at   
  348                          the parent in [RFC8078].                          
  349                                                                            
  350    NULL is a special case; see [RFC8078].                                  
  351                                                                            
  352    SHA-1 is still widely used for Delegation Signer (DS) records, so       
  353    validators MUST implement validation, but it MUST NOT be used to        
  354    generate new DS and CDS records (see "Operational Considerations" for   
  355    caveats when upgrading from the SHA-1 to SHA-256 DS algorithm.)         
  356                                                                            
  357    SHA-256 is widely used and considered strong.                           
  358                                                                            
  359    GOST R 34.11-94 has been superseded by GOST R 34.11-2012 in             
  360    [RFC6986].  GOST R 34.11-2012 has not been standardized for use in      
  361    DNSSEC.                                                                 
  362                                                                            
  363    SHA-384 shares the same properties as SHA-256 but offers a modest       
  364    security advantage over SHA-256 (384 bits of strength versus 256        
  365    bits).  For most applications of DNSSEC, SHA-256 should be              
  366    satisfactory and robust for the foreseeable future and is therefore     
  367    recommended for DS and CDS records.  While it is unlikely for a         
  368    DNSSEC use case requiring 384-bit security strength to arise, SHA-384   
  369    is provided for such applications, and it MAY be used for generating    
  370    DS and CDS records in these cases.                                      
  371                                                                            
  372 3.4.  DS and CDS Algorithm Recommendation                                  
  373                                                                            
  374    An operational recommendation for new and existing deployments:         
  375    SHA-256 is the RECOMMENDED DS and CDS algorithm.                        
  376                                                                            
  377                                                                            
  378                                                                            
  379                                                                            
  380                                                                            
  381                                                                            
  382 Wouters & Sury               Standards Track                    [Page 7]   

  383 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  384                                                                            
  385                                                                            
  386 4.  Security Considerations                                                
  387                                                                            
  388    The security of cryptographic systems depends on both the strength of   
  389    the cryptographic algorithms chosen and the strength of the keys used   
  390    with those algorithms.  The security also depends on the engineering    
  391    of the protocol used by the system to ensure that there are no non-     
  392    cryptographic ways to bypass the security of the overall system.        
  393                                                                            
  394    This document concerns itself with the selection of cryptographic       
  395    algorithms for use in DNSSEC, specifically with the selection of        
  396    "mandatory-to-implement" algorithms.  The algorithms identified in      
  397    this document as MUST or RECOMMENDED to implement are not known to be   
  398    broken (in the cryptographic sense) at the current time, and            
  399    cryptographic research so far leads us to believe that they are         
  400    likely to remain secure into the foreseeable future.  However, this     
  401    isn't necessarily forever, and it is expected that new revisions of     
  402    this document will be issued from time to time to reflect the current   
  403    best practices in this area.                                            
  404                                                                            
  405    Retiring an algorithm too soon would result in a zone (signed with a    
  406    retired algorithm) being downgraded to the equivalent of an unsigned    
  407    zone.  Therefore, algorithm deprecation must be done very slowly and    
  408    only after careful consideration and measurement of its use.            
  409                                                                            
  410 5.  Operational Considerations                                             
  411                                                                            
  412    DNSKEY algorithm rollover in a live zone is a complex process.  See     
  413    [RFC6781] and [RFC7583] for guidelines on how to perform algorithm      
  414    rollovers.                                                              
  415                                                                            
  416    DS algorithm rollover in a live zone is also a complex process.         
  417    Upgrading an algorithm at the same time as rolling a new Key Signing    
  418    Key (KSK) will lead to DNSSEC validation failures.  Administrators      
  419    MUST complete the process of the DS algorithm upgrade before starting   
  420    a rollover process for a new KSK.                                       
  421                                                                            

RFC9157 replaces this paragraph with the following:

This document provides recommendations with respect to mandatory-
to-implement algorithms, algorithms so weak that they cannot be
recommended, and algorithms defined in RFCs that are not on the
standards track.  Any algorithm listed in the [DNSKEY-IANA] and
[DS-IANA] registries that are not mentioned in this document MAY
be implemented.  For clarification and consistency, an algorithm
will be specified as MAY in this document only when it has been
downgraded from a MUST or a RECOMMENDED to a MAY.
  422 6.  IANA Considerations                                                    
  423                                                                            
  424    This document has no IANA actions.                                      
  425                                                                            
  426                                                                            
  427                                                                            
  428                                                                            
  429                                                                            
  430                                                                            
  431                                                                            
  432                                                                            
  433                                                                            
  434                                                                            
  435                                                                            
  436                                                                            
  437 Wouters & Sury               Standards Track                    [Page 8]   

  438 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  439                                                                            
  440                                                                            
  441 7.  References                                                             
  442                                                                            
  443 7.1.  Normative References                                                 
  444                                                                            
  445    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  446               Requirement Levels", BCP 14, RFC 2119,                       
  447               DOI 10.17487/RFC2119, March 1997,                            
  448               <https://www.rfc-editor.org/info/rfc2119>.                   
  449                                                                            
  450    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  451               Rose, "Resource Records for the DNS Security Extensions",    
  452               RFC 4034, DOI 10.17487/RFC4034, March 2005,                  
  453               <https://www.rfc-editor.org/info/rfc4034>.                   
  454                                                                            
  455    [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS      
  456               Security (DNSSEC) Hashed Authenticated Denial of             
  457               Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,      
  458               <https://www.rfc-editor.org/info/rfc5155>.                   
  459                                                                            
  460    [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY      
  461               and RRSIG Resource Records for DNSSEC", RFC 5702,            
  462               DOI 10.17487/RFC5702, October 2009,                          
  463               <https://www.rfc-editor.org/info/rfc5702>.                   
  464                                                                            
  465    [RFC6605]  Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital       
  466               Signature Algorithm (DSA) for DNSSEC", RFC 6605,             
  467               DOI 10.17487/RFC6605, April 2012,                            
  468               <https://www.rfc-editor.org/info/rfc6605>.                   
  469                                                                            
  470    [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature    
  471               Algorithm (DSA) and Elliptic Curve Digital Signature         
  472               Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August   
  473               2013, <https://www.rfc-editor.org/info/rfc6979>.             
  474                                                                            
  475    [RFC6986]  Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:      
  476               Hash Function", RFC 6986, DOI 10.17487/RFC6986, August       
  477               2013, <https://www.rfc-editor.org/info/rfc6986>.             
  478                                                                            
  479    [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating     
  480               DNSSEC Delegation Trust Maintenance", RFC 7344,              
  481               DOI 10.17487/RFC7344, September 2014,                        
  482               <https://www.rfc-editor.org/info/rfc7344>.                   
  483                                                                            
  484    [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital       
  485               Signature Algorithm (EdDSA)", RFC 8032,                      
  486               DOI 10.17487/RFC8032, January 2017,                          
  487               <https://www.rfc-editor.org/info/rfc8032>.                   
  488                                                                            
  489                                                                            
  490                                                                            
  491                                                                            
  492 Wouters & Sury               Standards Track                    [Page 9]   

  493 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  494                                                                            
  495                                                                            
  496    [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from    
  497               the Parent via CDS/CDNSKEY", RFC 8078,                       
  498               DOI 10.17487/RFC8078, March 2017,                            
  499               <https://www.rfc-editor.org/info/rfc8078>.                   
  500                                                                            
  501    [RFC8080]  Sury, O. and R. Edmonds, "Edwards-Curve Digital Security     
  502               Algorithm (EdDSA) for DNSSEC", RFC 8080,                     
  503               DOI 10.17487/RFC8080, February 2017,                         
  504               <https://www.rfc-editor.org/info/rfc8080>.                   
  505                                                                            
  506    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  507               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  508               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  509                                                                            
  510 7.2.  Informative References                                               
  511                                                                            
  512    [RFC5933]  Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of     
  513               GOST Signature Algorithms in DNSKEY and RRSIG Resource       
  514               Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July    
  515               2010, <https://www.rfc-editor.org/info/rfc5933>.             
  516                                                                            
  517    [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC             
  518               Operational Practices, Version 2", RFC 6781,                 
  519               DOI 10.17487/RFC6781, December 2012,                         
  520               <https://www.rfc-editor.org/info/rfc6781>.                   
  521                                                                            
  522    [RFC6944]  Rose, S., "Applicability Statement: DNS Security (DNSSEC)    
  523               DNSKEY Algorithm Implementation Status", RFC 6944,           
  524               DOI 10.17487/RFC6944, April 2013,                            
  525               <https://www.rfc-editor.org/info/rfc6944>.                   
  526                                                                            
  527    [RFC7091]  Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:      
  528               Digital Signature Algorithm", RFC 7091,                      
  529               DOI 10.17487/RFC7091, December 2013,                         
  530               <https://www.rfc-editor.org/info/rfc7091>.                   
  531                                                                            
  532    [RFC7583]  Morris, S., Ihren, J., Dickinson, J., and W. Mekking,        
  533               "DNSSEC Key Rollover Timing Considerations", RFC 7583,       
  534               DOI 10.17487/RFC7583, October 2015,                          
  535               <https://www.rfc-editor.org/info/rfc7583>.                   
  536                                                                            
  537    [DNSKEY-IANA]                                                           
  538               IANA, "Domain Name System Security (DNSSEC) Algorithm        
  539               Numbers",                                                    
  540               <http://www.iana.org/assignments/dns-sec-alg-numbers>.       
  541                                                                            
  542                                                                            
  543                                                                            
  544                                                                            
  545                                                                            
  546                                                                            
  547 Wouters & Sury               Standards Track                   [Page 10]   

  548 RFC 8624             DNSSEC Cryptographic Algorithms           June 2019   
  549                                                                            
  550                                                                            
  551    [DS-IANA]  IANA, "Delegation Signer (DS) Resource Record (RR) Type      
  552               Digest Algorithms",                                          
  553               <http://www.iana.org/assignments/ds-rr-types>.               
  554                                                                            
  555 Acknowledgements                                                           
  556                                                                            
  557    This document borrows text from RFC 4307 by Jeffrey I. Schiller of      
  558    the Massachusetts Institute of Technology (MIT) and RFC 8247 by Yoav    
  559    Nir, Tero Kivinen, Paul Wouters, and Daniel Migault.  Much of the       
  560    original text has been copied verbatim.                                 
  561                                                                            
  562    We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur      
  563    Gudmundsson, Paul Hoffman, Evan Hunt, and Peter Yee for their           
  564    feedback.                                                               
  565                                                                            
  566    Kudos to Roy Arends for bringing the DS rollover issue to light.        
  567                                                                            
  568 Authors' Addresses                                                         
  569                                                                            
  570    Paul Wouters                                                            
  571    Red Hat                                                                 
  572    Canada                                                                  
  573                                                                            
  574    Email: pwouters@redhat.com                                              
  575                                                                            
  576                                                                            
  577    Ondrej Sury                                                             
  578    Internet Systems Consortium                                             
  579    Czech Republic                                                          
  580                                                                            
  581    Email: ondrej@isc.org                                                   
  582                                                                            
  583                                                                            
  584                                                                            
  585                                                                            
  586                                                                            
  587                                                                            
  588                                                                            
  589                                                                            
  590                                                                            
  591                                                                            
  592                                                                            
  593                                                                            
  594                                                                            
  595                                                                            
  596                                                                            
  597                                                                            
  598                                                                            
  599                                                                            
  600                                                                            
  601                                                                            
  602 Wouters & Sury               Standards Track                   [Page 11]   
  603                                                                            
section-6 Mats Dufberg(Technical Erratum #6227) [Reported]
based on outdated version
   This document has no IANA actions.

It should say:
   This document updates the IANA registry "Delegation Signer (DS) Resource 
   Record (RR) Type Digest Algorithms". The registry has been updated by
   the following table from section 3.3:

   +--------+-----------------+-------------------+-------------------+
   | Number | Mnemonics       | DNSSEC Delegation | DNSSEC Validation |
   +--------+-----------------+-------------------+-------------------+
   | 0      | NULL (CDS only) | MUST NOT [*]      | MUST NOT [*]      |
   | 1      | SHA-1           | MUST NOT          | MUST              |
   | 2      | SHA-256         | MUST              | MUST              |
   | 3      | GOST R 34.11-94 | MUST NOT          | MAY               |
   | 4      | SHA-384         | MAY               | RECOMMENDED       |
   +--------+-----------------+-------------------+-------------------+

   [*] - This is a special type of CDS record signaling removal of DS at
         the parent in [RFC8078].


   This document updates the IANA registry "DNS Security Algorithm Numbers". 
   The registry has been updated by the following table from section 3.1:

   +--------+--------------------+-----------------+-------------------+
   | Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |
   +--------+--------------------+-----------------+-------------------+
   | 1      | RSAMD5             | MUST NOT        | MUST NOT          |
   | 3      | DSA                | MUST NOT        | MUST NOT          |
   | 5      | RSASHA1            | NOT RECOMMENDED | MUST              |
   | 6      | DSA-NSEC3-SHA1     | MUST NOT        | MUST NOT          |
   | 7      | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST              |
   | 8      | RSASHA256          | MUST            | MUST              |
   | 10     | RSASHA512          | NOT RECOMMENDED | MUST              |
   | 12     | ECC-GOST           | MUST NOT        | MAY               |
   | 13     | ECDSAP256SHA256    | MUST            | MUST              |
   | 14     | ECDSAP384SHA384    | MAY             | RECOMMENDED       |
   | 15     | ED25519            | RECOMMENDED     | RECOMMENDED       |
   | 16     | ED448              | MAY             | RECOMMENDED       |
   +--------+--------------------+-----------------+-------------------+



The document clearly has the intention to update the IANA registers, which is also stated in the document, but not in section 6 ("IANA Considerations").

The following IANA considerations are added by RFC9157:

In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3)
Parameters" registry, the registration procedure for "DNSSEC NSEC3
Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags"
has been changed from "Standards Action" to "RFC Required", and this
document has been added as a reference.

In the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type
Digest Algorithms" registry, the registration procedure for "Digest
Algorithms" has been changed from "Standards Action" to "RFC
Required", and this document has been added as a reference.