RFC 9906

RFC 9906: Deprecate Usage of ECC-GOST within DNSSEC ✨

Okay bestie, here's the tea 🫶 This is RFC 9906, and it's a Standards Track document (ISSN 2070-1721), published in November 2025. It was written by Wes Hardaker (USC/ISI) and Warren Kumari (Google). It updates RFC 5933 and doesn't obsolete anything. The whole point is to retire ECC-GOST in DNSSEC 💅

Abstract

So basically, this doc retires GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.11-94 inside DNSSEC 🥀

RFC 5933 (now Historic) is the one that originally defined the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNS Security Extensions (DNSSEC). This document updates RFC 5933 by deprecating ECC-GOST 🎀

Status of This Memo

This is an Internet Standards Track document ✨

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more info on Internet Standards, check Section 2 of RFC 7841 🌸

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9906 🦋

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 📜

Table of Contents

1.  Introduction
  1.1.  Requirements Notation
2.  Deprecating ECC-GOST Algorithms in DNSSEC
3.  Security Considerations
4.  Operational Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction

The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are documented in [RFC5933], and their use with DNS Security Extensions (DNSSEC) is further described in [RFC9364] 🧚

Here's the backstory: the Federal Agency for Technical Regulation and Metrology of Russia (Rosstandart) deprecated these two algorithms in August 2012. They were superseded by GOST 34.10-2012 and GOST 34.11-2012, respectively. The use of those newer algorithms in DNSSEC is documented in [RFC9558], and this document doesn't change their associated requirement levels 🌈

So the bottom line: the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.11-94 is no longer recommended for use in DNSSEC [RFC9364] 💀

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀

2. Deprecating ECC-GOST Algorithms in DNSSEC

Okay, this is the important part, so pay attention 👑

The GOST R 34.11-94 algorithm [RFC5933] MUST NOT be used when creating Delegation Signer (DS) records. Validating resolvers MUST treat GOST R 34.11-94 DS records as insecure. If no other DS records of accepted cryptographic algorithms are available, the DNS records below the delegation point MUST be treated as insecure 🔥

The GOST R 34.10-2001 algorithm [RFC5933] (mnemonic "ECC-GOST") MUST NOT be used when creating DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records. Validating resolvers MUST treat RRSIG records created from DNSKEY records using these algorithms as unsupported algorithms. If no other RRSIG records of accepted cryptographic algorithms are available, the validating resolver MUST consider the associated resource records as insecure 😭

3. Security Considerations

This one's a glow-up for security! This document potentially increases the security of the DNSSEC ecosystem by deprecating algorithms that are no longer recommended for use 🛡️✨

4. Operational Considerations

This document removes support for ECC-GOST. Zone operators who are currently using ECC-GOST-based algorithms should switch to algorithms that are still supported. DNS registries should prohibit their clients from uploading and publishing ECC-GOST-based DS records, so that everyone is using algorithms that DNSSEC validators support and that can therefore be DNSSEC validated 🍓

5. IANA Considerations

IANA has updated the GOST R 34.10-2001 (12) entry in the "DNS Security Algorithm Numbers" registry [DNSKEY-IANA] [RFC9904] like so 💖

Number:  12
Description:  GOST R 34.10-2001 (DEPRECATED)
Mnemonic:  ECC-GOST
Zone Signing:  Y
Trans.  Sec.:  *
Use for DNSSEC Signing:  MUST NOT
Use for DNSSEC Validation:  MUST NOT
Implement for DNSSEC Signing:  MUST NOT
Implement for DNSSEC Validation:  MUST NOT
Reference:  [RFC5933], Change the status of GOST Signature Algorithms
   in DNSSEC in the IETF stream to Historic
   (https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-
   historic/), and RFC 9906

Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" columns were already set to MUST NOT. 🙈

IANA has also updated the GOST R 34.11-94 (3) entry in the "Digest Algorithms" registry [DS-IANA] like this 🦋

Value:  3
Description:  GOST R 34.11-94 (DEPRECATED)
Use for DNSSEC Delegation:  MUST NOT
Use for DNSSEC Validation:  MUST NOT
Implement for DNSSEC Delegation:  MUST NOT
Implement for DNSSEC Validation:  MUST NOT
Reference:  [RFC5933], Change the status of GOST Signature Algorithms
   in DNSSEC in the IETF stream to Historic
   (https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-
   historic/), and RFC 9906

Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" columns were already set to MUST NOT. 💅

6. References

6.1. Normative References

[DNSKEY-IANA]
   IANA, "DNS Security Algorithm Numbers",
   <https://www.iana.org/assignments/dns-sec-alg-numbers>.

[DS-IANA]
   IANA, "Digest Algorithms",
   <http://www.iana.org/assignments/ds-rr-types>.

[RFC2119]
   Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119,
   DOI 10.17487/RFC2119, March 1997,
   <https://www.rfc-editor.org/info/rfc2119>.

[RFC5933]
   Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of
   GOST Signature Algorithms in DNSKEY and RRSIG Resource
   Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July
   2010, <https://www.rfc-editor.org/info/rfc5933>.

[RFC8174]
   Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
   2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
   May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9364]
   Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
   RFC 9364, DOI 10.17487/RFC9364, February 2023,
   <https://www.rfc-editor.org/info/rfc9364>.

[RFC9904]
   Hardaker, W. and W. Kumari, "DNSSEC Cryptographic
   Algorithm Recommendation Update Process", RFC 9904,
   DOI 10.17487/RFC9904, November 2025,
   <https://www.rfc-editor.org/info/rfc9904>.

6.2. Informative References

[RFC9558]
   Makarenko, B. and V. Dolmatov, Ed., "Use of GOST 2012
   Signature Algorithms in DNSKEY and RRSIG Resource Records
   for DNSSEC", RFC 9558, DOI 10.17487/RFC9558, April 2024,
   <https://www.rfc-editor.org/info/rfc9558>.

Acknowledgments

Huge thanks to the following IETF participants for their comments and suggestions while this doc was being made: Mark Andrews, Steve Crocker, Brian Dickson, Peter Dickson, Thomas Graf, Paul Hoffman, Russ Housely, Shumon Huque, S. Moonesamy, Peter Thomassen, Stefan Ubbink, Tim Wicinski, Paul Wouters, and the many members of the DNSOP Working Group who discussed this specification 🫶🌸

Authors' Addresses

Wes Hardaker
USC/ISI
Email: ietf@hardakers.net

Warren Kumari
Google
Email: warren@kumari.net