Summary

  • RFC 9904 makes the IANA DNSSEC registries the canonical source for separate use and implementation recommendations in signing, delegation and validation.
  • RFC 9905 marks new SHA-1-based signing and delegation creation MUST NOT while retaining validation support. A compliant registry state is therefore the start of an operational migration record, not proof that a zone has rolled.

The table had changed. Beside RSASHA1, the signing-use column now said MUST NOT. The live zone still served a SHA-1 DNSKEY and signatures, and its parent still carried delegation material from the old arrangement. No contradiction had occurred. One coordination record had moved; the distributed system had not yet completed its own sequence.

RFC 9904, published in November 2025, moved the canonical DNSSEC algorithm recommendations from RFC 8624 into IANA's registries. Its RFC Editor record fixes the status and its relationship to the earlier documents, including RFC 9157. RFC 9904 did not itself change the inherited recommendation levels. It changed where later decisions would be recorded.

The new shape matters more than the location. The DNS Security Algorithm Numbers registry separately asks whether an algorithm should be used for signing, used for validation, implemented by signing software and implemented by validating software. The DS digest registry applies the same discipline to delegation creation and validation. A single label such as “supported” can no longer conceal four different obligations.

RFC 9905 exercised that design. RSASHA1 and RSASHA1-NSEC3-SHA1 must not be used to create new DNSKEY, RRSIG or DS material. Yet validating resolver implementations must continue to support those signature algorithms during their declining but still active use. The current tables therefore say, in effect: stop adding dependence, but do not strand remaining zones before they can leave it.

That asymmetry is migration engineering, not indecision. An operator can change a policy document in one instant. A signed delegation crosses several owners and clocks. Signing software produces DNSKEY and RRSIG data in the child. A registrar or registry path changes DS data in the parent. Authoritative servers converge on a zone serial. Recursive caches retain earlier records until their TTLs expire. Validators differ by version, supported algorithms and observation time.

The validation result also needs a name. RFC 9364 places DNSSEC's origin-authentication practice in its wider protocol family, while RFC 4035 distinguishes secure, insecure, bogus and indeterminate outcomes. RFC 9905 specifies insecure treatment in defined SHA-1 cases when no accepted alternative validates the delegation or response. It does not license a blanket statement that every SHA-1-bearing zone is bogus or unreachable.

Rollover order is where a symbolic completion claim becomes dangerous. RFC 9904 warns that changing the DS algorithm together with a new KSK can cause validation failure and requires the DS algorithm upgrade first. RFC 6781 shows why: adding or removing an algorithm requires staged RRSIG, DNSKEY and DS transitions separated by propagation and cache-expiry windows. A green signer job can be true while distant validators still see an unsafe combination.

A defensible closeout therefore joins several receipts. Preserve the IANA snapshot and authorizing RFC, signer software and configuration revision, zone serial, exact DNSKEY/RRSIG/DS sets, parent transaction receipt, authoritative observations from independent vantage points, TTL windows, validator versions and results, error telemetry, rollback state and the application objective. Each item answers one question; none should inherit the authority of the whole chain.

Heng Lu's Minimum Initial Specification supports a narrow common table while leaving rollout choices with accountable operators. Running-Code Primacy demands live record and validator evidence. Reality Layers keeps a recommendation, a configuration, a published RRset and a user-visible result from collapsing into one institutional statement. These are disclosed editorial principles, not extra DNSOP requirements.

The registry can say which direction the ecosystem must travel. Only an observed, time-bound chain can show that one zone and its validators arrived.

Sources