Summary

  • On 1 September 2026, the DNSOP chairs found clear support for adopting draft-huque-dnsop-multi-alg-rules-08 while expressly carrying complexity concerns into further Working Group work.
  • The draft would let a signer omit some advertised-algorithm signatures when at least one proposed UNIVERSAL algorithm is present and no FORMERLY-UNIVERSAL algorithm is present.
  • Those labels would also affect how a validator treats a locally disabled algorithm, so they are operational inputs rather than descriptive badges.
  • Daniel Kade proposes a separate, dated deployment-evidence receipt for every future algorithm-classification change. Adoption records the problem selected for work; Standards Action would have to authorize the classification.

The chairs preserved both halves of the result

The DNSOP adoption close is unusually economical. The chairs say there is clear support for adopting the document. In the next sentence they say concerns about the proposed mechanism’s complexity should be addressed in the Working Group’s further work. Neither sentence cancels the other.

The call opened on 13 August and ended on 31 August. The current Datatracker record now marks the active Internet-Draft as “Adopted by a WG.” It still shows the IESG state as “I-D Exists,” with no telechat date, responsible Area Director or document shepherd listed. Revision 08 remains a work in progress, not an RFC and not an IETF-approved rule.

That boundary matters because adoption is a routing decision. It moves a problem and a proposed solution into the Working Group’s change control. It does not freeze the submitted text. In this case the chairs explicitly identify further revision as part of the outcome.

The old rule buys certainty by requiring the full set

RFC 4035 requires an RRSIG made with at least one key of every algorithm in the zone-apex DNSKEY set, and requires the apex DNSKEY set to be signed by every algorithm in the parent’s DS set. RFC 6840 restates the signer obligation: a DNSKEY must exist for every algorithm signalled by the DS set or expected trust anchors, and the zone must be signed with every algorithm present in the DNSKEY set. Validators, by contrast, should accept any valid path.

That asymmetry is deliberate. A signer generally cannot know which algorithms every validator supports. Serving the complete advertised set prevents a missing supported signature from looking like a downgrade. The cost is coordination. RFC 8901 says multi-signer providers need a common signing algorithm under the present rules. A zone cannot smoothly use two providers with disjoint algorithm sets merely by publishing both providers’ keys.

The exact revision 08 text treats that as an operational constraint worth relaxing. Its use cases include permanent multi-signer service, a transfer between providers that do not share an algorithm, separate KSK and ZSK changes, pre-publication of a trust anchor and experimental introduction of a new algorithm without coordinating every provider at once.

Those are real classes of problem. Adopting the draft says DNSOP will work on them. It does not say that every proposed state or consequence has survived review.

A registry word would change packet behaviour

The draft proposes a new IANA column named Validation support status. Its values would be UNIVERSAL, FORMERLY-UNIVERSAL or empty. Algorithms 8 and 13 would initially be UNIVERSAL; none would initially be FORMERLY-UNIVERSAL. The live IANA DNSSEC algorithm registry does not yet have that column. It does show algorithms 8 and 13 as MUST to implement for DNSSEC validation.

The proposed label is executable policy. If an advertised DS or trust-anchor set contains at least one UNIVERSAL algorithm and no FORMERLY-UNIVERSAL algorithm, the signer would need to serve a signature for only one UNIVERSAL algorithm. Other advertised-algorithm signatures become optional. In other combinations, all advertised algorithms remain required.

The validator side is equally consequential. A validator that does not support an advertised UNIVERSAL or FORMERLY-UNIVERSAL algorithm would treat the zone as unsigned, even if another advertised algorithm is supported. Otherwise it would accept any valid path. To behave this way after locally disabling an algorithm, the validator must remember whether that algorithm is or once was UNIVERSAL.

So the classification is not praise, popularity or a marketing shorthand. It changes what a signer may omit and whether a validator returns an insecure answer rather than a bogus result in a defined case. A stale or premature classification can therefore travel into availability and security outcomes.

RFC 9904 already supplies a useful separation. It moved canonical algorithm implementation and use recommendations into IANA registries, while distinguishing what implementations need for interoperability from what operators should deploy. It expects recommendations to change and normally expects retirement to be gradual. The new draft adds a different state with different consequences; it should not borrow authority merely because it would sit beside existing recommendation columns.

Support for work did not erase opposition to the design

The public thread contains more than an approval count. Mark Andrews opposed the draft and disputed its worldwide validator-support premise. Paul Hoffman supported relaxing the old “every algorithm” requirement but opposed the current UNIVERSAL and FORMERLY-UNIVERSAL design. Paul Wouters supported adoption while asking for substantial simplification and clearer separation of scenarios.

These are individual interventions, not three institutional votes with equal weight and not a substitute for the chairs’ judgment. Their relevance is narrower: the objections the closing message preserves can be located in the record. The Working Group accepted custody of a contested design rather than declaring the contest over.

The draft itself identifies the hardest fact. Protocol machinery cannot determine universal support. It says the community must advance an algorithm only when the validator population lacking support is deemed negligible. “Deemed negligible” is a governance threshold attached to an empirical population that is hard to enumerate.

Give every lifecycle change its own receipt

A later Standards Action should therefore carry evidence that is separate from the adoption history. For each move into UNIVERSAL or FORMERLY-UNIVERSAL, a compact receipt should name the exact algorithm and registry version, the measurement date, the observed validator cohort, known exclusions and old implementations, and the rule used to judge the unsupported population negligible.

It should also show expected Secure, Insecure and Bogus outcomes for representative multi-signer and provider-transfer states; interaction with local algorithm preferences; the effective window; signer and provider dependencies; and the owner of an emergency reversal or transition. The receipt need not expose resolver identities or proprietary fleet data. It must expose enough to distinguish an interoperability claim from an assumption.

This follows Heng Lu’s minimum-common-layer discipline. A shared classification is justified only for the interoperability fact that independent operators must coordinate. Local preference—such as choosing among otherwise supported algorithms—should remain local unless a later standards decision deliberately and openly changes that boundary. A registry row may record the common state; it should not silently convert one operational preference into a universal command.

DNSOP has now made the first decision: this problem belongs in the Working Group. The chairs also preserved the condition on that decision: complexity remains open. The next record should make equally clear when the mechanism changes, what evidence supports its most powerful label and which authority finally approves it.

Sources