Summary

  • RFC 9905 is an IETF Standards Track document from November 2025 that updates RFC 4034 and RFC 5155.
  • RSASHA1 and RSASHA1-NSEC3-SHA1 MUST NOT create DS, DNSKEY or RRSIG records. Affected DS-only delegations are treated as insecure when no other accepted DS path exists.
  • Validator implementations MUST continue to implement validation with these algorithms. That duty is separate from the prohibition on signing and from the insecure-delegation outcome.

The mechanism is visible in the registry rows: production is marked MUST NOT, while validation implementation remains a requirement for continuity. RFC 9905 therefore does not say that every validator may remove SHA-1 now. It says operators should move zones to stronger algorithms recommended by the IANA registries, while the consuming side retains the ability to validate material still present during transition. Software that already removed SHA-1 validation may need a manual build to meet that implementation duty.

The operational sequence has three distinct checkpoints. First, the authoritative signer must stop generating RSASHA1 and RSASHA1-NSEC3-SHA1 DNSKEY and RRSIG records. Second, the delegation owner must stop creating DS records with those algorithms and publish an accepted stronger DS path before withdrawing the old path. Third, recursive validation infrastructure must retain implementation support and test its ability to validate remaining legacy data. A new signing configuration alone is not evidence that the delegation or recursive fleet has migrated.

A controlled change uses overlap. Publish and validate the stronger DNSKEY and RRSIG material, publish the stronger DS, and observe successful recursive validation while the old path remains available only as a transition artifact. Record authoritative responses, DS sets, DNSKEY and RRSIG retrieval, validation results, and cache-aware timing. Rollback evidence is equally concrete: preserve the prior zone and key configuration, document the last known-good DS state, and define how to restore the previous accepted configuration without creating new SHA-1 material. Rollback must not be confused with permission to resume prohibited production.

Concrete checks:

  1. Search signer configuration and generated zones for RSASHA1 and RSASHA1-NSEC3-SHA1 DNSKEY or RRSIG output; the result should be zero for new production.
  2. Inspect parent DS publication separately. Confirm that the intended stronger algorithm is present and that no SHA-1-only delegation is being treated as secure.
  3. Test a recursive validator against remaining legacy fixtures and a stronger-algorithm zone. Record validation outcomes and the implementation version or build options.
  4. Check whether the deployed software removed SHA-1 validation. If so, plan a manual build or another implementation path that satisfies the continuing validation requirement.

This is a software-lifecycle-and-lock-in problem as much as a cryptographic one: an early removal decision can eliminate the compatibility needed for the installed base, while an unchanged signer can violate the new production rule. The frozen sources provide no current adoption, vendor, incident, performance, or future registry-change data, so those questions require separate evidence.

Sources