Summary

  • RFC 9558 assigns DNSSEC algorithm 23 to GOST R 34.10-2012 and DS digest type 5 to GOST R 34.11-2012, with an exact key, signature and digest profile.
  • The document is an Informational Independent Submission without IETF consensus; it explicitly does not establish cryptographic suitability, implementation value or deployment support.
  • A trustworthy result needs distinct receipts for registry assignment, signer support, exact wire objects, parent DS publication, validator capability, chain validation, resolver status and application observation.

The registry drawer opened; the resolver gate stayed shut

Picture a zone operator completing what looks like a meticulous deployment. A 64-octet public key is published under algorithm 23. RRSIG records carry correctly formed 512-bit signatures. The parent has a DS record using digest type 5. Every object can be decoded against RFC 9558.

One recursive resolver validates the zone through a second algorithm. Another has no implementation for GOST 2012. It disregards the unsupported path and treats the child as though it were unsigned. The records did not disappear. Their meaning did not change. The validator's capability changed what conclusion could be reached.

That is the operational value of RFC 9558. It is easy to read an IANA assignment as arrival: the algorithm now “exists” in DNSSEC. In fact, assignment is the first coordinate in a longer chain. The registry gives implementations a shared label. It does not install code, publish a DS, prove a signature, configure a trust anchor or carry authenticated status into an application.

Publication status is part of the evidence

RFC 9558 was published in April 2024 as Informational on the Independent Submission stream. The status language is unusually important. It is not an Internet Standards Track specification, does not have IETF community consensus and is not endorsed by the IETF standards process. The RFC Editor says its publication makes no statement about value for implementation or deployment.

The document adds a second warning. GOST R 34.10-2012 and GOST R 34.11-2012 are Russian national standards whose cryptographic properties, in this context, have not been independently verified. Neither the IETF nor the IRTF analyzed the algorithms for suitability for any application. A careful operator must preserve those statements alongside the technical profile. “Published as an RFC” and “recommended by the IETF” are not synonyms.

This is not a verdict against use. It is a boundary around what the record can support. The RFC makes interoperation possible for parties that choose the suite. It does not decide whether a particular relying party should accept it.

The profile is narrow because interoperability is unforgiving

RFC 9558 selects the 256-bit signature variant, the 256-bit digest variant and id-tc26-gost-3410-2012-256-paramSetA. A public key is an elliptic-curve point Q=(x,y), encoded in exactly 64 octets: 32 little-endian octets for x followed by 32 little-endian octets for y. Public keys and signatures are each 512 bits; the digest is 256 bits.

That byte order is not editorial detail. A point can be mathematically valid in a library and still be represented incorrectly in a DNSKEY record. RFC 9558 even supplies a fixed 30-byte ASN.1 SubjectPublicKeyInfo prefix so an implementation can wrap the DNS wire value for existing GOST-aware X.509 APIs. The wrapper is an adapter between formats. It is not a certificate, trust anchor or authorization.

For RRSIG, the RFC applies GOST R 34.11-2012 to the RFC 4034 signing input and calculates a GOST R 34.10-2012 signature. Its example discloses a pseudorandom integer k so readers can reproduce the output, then warns that the value must never be used for real signatures. A test vector proves agreement with one example. Reusing its nonce would convert reproducibility into key exposure.

Two numbers name objects; they do not join the chain

IANA lists ECC-GOST12 as DNSSEC algorithm 23 and GOST R 34.11-2012 as DS digest type 5. These are separate registries because the objects do separate work. Algorithm 23 tells a validator how to interpret the DNSKEY and RRSIG. Digest type 5 tells it how the parent-side DS binds to the child DNSKEY.

A correct RRSIG without a usable delegation path is not an authenticated child. A matching DS without supported algorithms is not a supported path. A supported implementation without the correct parent DS has nothing to bridge. A valid chain outside the signature's time window is not a current validation result.

The minimum audit record should therefore keep the exact DNSKEY RRset, RRSIG set, DS RRset, authoritative observation point, parent observation point, signature times, trust anchor, validator software and algorithm inventory together. A dashboard badge that says “DNSSEC enabled” compresses all of these into a statement too broad to investigate.

Unsupported does not mean bogus

The most consequential boundary appears in the interaction with RFC 6840 and RFC 4035. RFC 9558 makes suite support optional. When a validator encounters authenticated DS records whose public-key algorithm or message-digest algorithm it does not support, it disregards those records. If no supported authentication path remains, the zone is treated as though it were unsigned.

That is different from a bogus result. Bogus means a path that should validate failed the relevant checks. Unsupported can remove the path before signature verification is possible. The distinction protects interoperability, but it also creates heterogeneous reality: one validator may authenticate the same zone that another treats as insecure.

The right incident question is not merely “Was the signature valid?” It is “Which validator, with which supported algorithm set and trust-anchor state, evaluated which RRsets at what time, and what security status did it return?” Without that tuple, a successful command-line test cannot speak for a resolver fleet.

Dual signing is a bridge with its own failure modes

RFC 9558 recommends a dual-KSK algorithm-signed zone until GOST-aware DNSSEC software is more widespread, unless GOST-only cryptography is deliberate. The recommendation acknowledges deployment reality. A second supported path can keep authentication available to validators that do not implement algorithm 23.

But dual signing is not a magic compatibility switch. It adds state: multiple KSKs, DS records, signatures, rollover schedules, caches and removal decisions. RFC 6840 advises validators to accept any valid RRSIG as sufficient and to declare an RRset bogus only if all tested signatures fail. That policy enables mixed-algorithm operation, while cache timing and restrictive local policy can still create divergent results.

A transition needs named entry and exit criteria. Before adding the new path, measure validator capability in the populations that matter. Before removing the old path, verify parent DS state, authoritative publication, cache ageing and external validation from independent networks. “Both keys are visible” is not a withdrawal receipt.

Validation stops before the application outcome

Even a fully supported and valid chain proves a bounded proposition: the RRset is authenticated relative to a configured trust anchor under DNSSEC rules. It does not prove the zone operator's legal identity, the safety of the algorithm for every policy, the availability of the named service, or the effect of a later connection.

The resolver-to-client boundary matters too. DO asks for DNSSEC records. CD changes checking behavior. AD communicates authenticated-data status under specified conditions. A stub that receives an answer over an untrusted channel cannot simply promote a bit into end-to-end proof. An application that never consumes the status cannot claim a security decision from it.

The complete receipt chain ends only after the application identifies the resolver it trusts, records the returned security status, acts under a defined policy and observes the scoped result. DNSSEC can authenticate data. It cannot certify everything the data is later used to do.

Sources

Sources