Summary

  • RFC 9904 is an IETF Standards Track RFC from November 2025. It formally replaces (obsoletes) RFC 8624 and updates RFC 9157.
  • It moves canonical DNSSEC algorithm implementation requirements and usage guidance into the IANA DNS Security Algorithm Numbers and DS Digest Algorithms registries.
  • The four cells are not interchangeable: validator and signer implementation duties can differ, as can recommendations for validation use and signing use.
  • RFC 9904 does not itself change any MUST, MAY, RECOMMENDED, or other recommendation status inherited from RFC 8624. A later change requires Standards Action and transition and interoperability reasoning.

The mechanism matters because an algorithm number is not a single policy switch. The registry can represent four distinct questions: whether validators must or should implement the algorithm; whether signers must or should implement it; whether it is recommended for validating data; and whether it is recommended for signing data. Keeping those questions apart makes asymmetric migration visible. A signer policy can therefore differ from a validator requirement without treating the two roles as identical.

RFC 9904 replaces the need for a complete, periodically replaced static recommendation table in an omnibus RFC with a governed registry control surface. The registry becomes the canonical place to consult for recommendation guidance after RFC 9904. The RFC text remains the authority for the process: future RFCs may revise the columns through Standards Action, and the change description must address transition and interoperability consequences. This does not permit IANA to alter recommendation values without that action.

The starting point is deliberately conservative. RFC 9904 relocates the guidance inherited from RFC 8624; it does not announce a new algorithm verdict. RFC 9157 supplies updated DNSSEC registry-considerations context, while RFC 9364 supplies protocol context for DNSSEC authentication and denial-of-existence proofs. The frozen sources do not establish current adoption, vendor support, incident frequency, performance, migration cost, or a future cryptographic judgment.

Theo March analysis: the operational decision record should capture a timestamped snapshot of both relevant IANA registries, the source and observation time, and the four cells that informed the policy. Where deployment permits, the record should include overlap-test results for the old and replacement algorithms, separate validator and signer coverage, any staged-change evidence, and rollback material. These are analytical change-control recommendations, not requirements imposed by RFC 9904.

The operational hazard described by RFC 9904 is concrete: retiring an algorithm too early can make a zone signed only with that algorithm appear effectively unsigned to validators. Deprecation should therefore be deliberate and ideally gradual. Theo March analysis translates that warning into a decision path: observe the relevant registry state, distinguish the roles, test overlap, stage a change where possible, and preserve evidence for rollback. The frozen source set does not establish whether such a scenario is current, common, fast, or costly.

Operator decision path

Theo March analysis:

  1. Observe: record the timestamped IANA DNS Security Algorithm Numbers and DS Digest Algorithms registry snapshots used for the decision.
  2. Classify: map the proposed action to validator implementation, signer implementation, validation use, or signing use; do not collapse the cells.
  3. Check: read the applicable RFC transition and interoperability reasoning, then test overlap across the relevant signing and validation paths.
  4. Stage: apply a deliberate, gradual change where possible, with evidence concerning whether the zone could appear effectively unsigned to validators.
  5. Recover: preserve rollback material, registry snapshots, test results, and the policy owner’s decision record.

These steps express Theo March analysis of the lifecycle-control problem; they are not additional RFC 9904 requirements.

Sources