Summary

  • RFC 9563 assigns DNSSEC algorithm 17 to SM2 with SM3 and DS digest type 6 to SM3, making the formats unambiguous on the wire.
  • The document is an Independent Stream Informational RFC, not an IETF Standards Track specification; it says the IETF and IRTF have not analyzed the algorithms’ suitability for this use.
  • A registry entry remains upstream of signer implementation, delegation material, validator capability, local policy, signature verification and the answer an application ultimately receives.

A validating resolver receives a signed response. The algorithm field contains 17. This is no longer an unknown number: the IANA registry says what it means. Yet the resolver may lack an SM2 implementation, may have no supported DS digest leading to the child, may reject the path under local policy, or may validate a signature without proving anything about private-key custody. Naming the algorithm is the beginning of the evidence chain, not its conclusion.

RFC 9563, published on 4 December 2024, defines how SM2 signatures and SM3 digests fit into DNSSEC records. It assigns algorithm 17, mnemonic SM2SM3, and digest type 6. It also draws a sharp authority boundary. The publication is Informational and comes from the Independent Stream. It is not the product of IETF community consensus. The text says neither the IETF nor the IRTF has analyzed whether these algorithms are suitable for the stated purpose, and warns that weaknesses may exist.

Those sentences are not ceremonial boilerplate. They identify exactly what the publication can prove.

Allocation removes ambiguity, not uncertainty

Without a code point, two implementations cannot reliably signal the same algorithm in a DNSKEY, RRSIG or DS record. Allocation therefore matters. It gives an interoperable name to a wire format and prevents private interpretations from colliding.

The current IANA DNS Security Algorithm Numbers registry records algorithm 17 and marks its use and implementation for signing and validation as MAY. The DS digest registry records type 6 with MAY recommendations. These are live registry facts observed on 27 September 2026. They are not usage measurements, procurement approvals or cryptanalytic evaluations.

RFC 6014’s allocation framework and the IANA tables solve namespace governance: who may assign a value, under what review rule, and what the value denotes. A registry can be correct even when no resolver in a given fleet implements the entry. Conversely, an implementation can exist before broad operational acceptance. Conflating those layers turns a catalogue into a deployment report.

RFC 7841 provides another guardrail. The header and boilerplate tell the reader which RFC stream published a document and what status it carries. The integer in “RFC 9563” identifies a durable publication. It does not erase “Independent Stream” or manufacture IETF consensus.

DNSSEC validation is a path, not a primitive

DNSSEC does not ask only whether one signature equation works. RFC 4033 separates authoritative servers, security-aware resolvers and trust anchors. RFC 4034 defines the DNSKEY, RRSIG, DS and denial-of-existence records. RFC 4035 then requires the validator to assemble an authentication path: select supported algorithms, find a matching key, reconstruct canonical data, check the signature’s time interval and verify it against an accepted chain.

Algorithm 17 can be parsed yet unsupported. The SM2 signature can be implemented while digest type 6 is not. A child can publish a DNSKEY while the parent delegation supplies no usable DS. A resolver can possess all primitives and still apply policy that declines the path.

RFC 6840 makes one surprising consequence explicit. An unsupported DS digest is disregarded like an unsupported DNSKEY algorithm. If no supported DS remains, a validator can treat the delegation as insecure rather than bogus. The zone may be signed and the registry may be precise, while a particular resolver cannot construct a supported authentication path.

This is why RFC 8624 maintains implementation and use recommendations. Algorithm agility has a coordination cost: signers and validators must overlap long enough to preserve reachability. RFC 8624 predates RFC 9563’s assignment, so its older table cannot prove present support for algorithm 17 or digest 6. Current support must be measured in actual software, builds, configurations and resolver populations.

A valid signature answers a bounded question

RFC 9563 defines the public-key and signature encodings needed to perform the cryptographic operation. A successful verification can show that the signed canonical DNS data matches a signature under the selected public key, within the validation rules and time window. That is valuable evidence. It does not show who controlled the private key, whether the use was authorized, whether a rollover preserved continuity, or whether the application accepted the returned address.

RFC 7583 treats generation, storage, rollover, compromise and retirement as operational work because keys live inside systems and institutions. RFC 9563 likewise requires crypto-agility: if weaknesses emerge, DS, DNSKEY, RRSIG and NSEC3 material may need replacement with cache-aware sequencing. A registry update cannot execute that transition.

The clean evidence chain is therefore: publication provenance; current registry state; signer build and configuration; observed DNSKEY, DS and RRSIG material; resolver algorithm support; trust-anchor and policy state; validation log; cache-aware rollover continuity; and application outcome. Each receipt proves a different event.

Heng Lu’s running-code principle gives the chain its discipline. Symbolic authority, configured intent, executable capability and observed result are all real, but none may impersonate another. RFC 9563 makes SM2 and SM3 speakable in DNSSEC. Only implementations and observations can show what happened after they were spoken.