Summary

  • RFC 9906 is an IETF Standards Track document from November 2025 that updates RFC 5933 and retires GOST R 34.10-2001 (ECC-GOST) and GOST R 34.11-94 within DNSSEC.
  • GOST R 34.11-94 MUST NOT create DS records. A delegation containing only that retired DS path is treated as insecure unless another accepted DS is present.
  • ECC-GOST MUST NOT create DNSKEY or RRSIG records. When legacy-only signatures are encountered, validators treat the associated RRSIGs as unsupported; without another accepted RRSIG, the associated records are considered insecure.
  • The distinct GOST 2012 algorithms documented in RFC 9558 are outside this retirement. RFC 9906 does not change their requirement levels.

What changed in the registry

RFC 9906’s important mechanism is the completed matrix. The affected cells for signing, validation, implementation, and use all say MUST NOT. That closes the path by which a legacy algorithm might still be produced and the path by which it might still be relied upon during validation. It also moves a practical enforcement point upstream: registries should prohibit ECC-GOST DS uploads and publication rather than accepting material that authoritative servers and resolvers are then expected to handle.

This is materially different from RFC 9905’s asymmetric SHA-1 compatibility transition. RFC 9906 does not preserve a corresponding validation lane for ECC-GOST. Its specified result for legacy-only material is insecure, not a claim that a resolver should classify the data as cryptographically invalid. Operators should therefore establish a supported algorithm path before removing legacy-only DS or RRSIG material.

The two retired paths are separate checks

For GOST R 34.11-94, inspect the parent-side delegation. It must not create a DS using that digest. If no other accepted DS exists, records below the delegation point must be treated as insecure. For ECC-GOST, inspect the child zone’s DNSKEY and RRSIG production. The zone must not create either record type with the retired algorithm. If only those RRSIGs are available, the associated resource records must be considered insecure.

The operational answer is to move zone signing to supported algorithms, publish and validate the replacement path, and keep evidence that the old path has been removed at every boundary. Do not apply this retirement to GOST 2012. RFC 9558 supplies the separate successor-family context; RFC 9906 leaves its requirement levels unchanged.

Sources