Summary

  • A new DNSOP working-group draft proposes that, when a zone's DS or trust-anchor set includes a designated UNIVERSAL algorithm and no FORMERLY-UNIVERSAL one, the zone may sign with at least one UNIVERSAL algorithm instead of every listed algorithm. It is an initial working-group draft, not an approved RFC.
  • The draft initially designates algorithms 8 and 13 as UNIVERSAL for validation. The live IANA algorithm registry currently marks both as mandatory to implement for validation; the proposed new support-status column has not been added.
  • A resolver that disables an advertised UNIVERSAL or FORMERLY-UNIVERSAL algorithm under local policy would classify the zone as unsigned, even when another advertised algorithm remains supported. That local decision trades authentication for availability and must be visible to the operator.

A DNS zone can advertise two cryptographic algorithms and still send a resolver one valid signature. That sounds like a trick until the current rule is read closely. RFC 4035 and RFC 6840 require the signer to produce signatures for every algorithm represented in the zone's DNSKEY set, while validators accept any one valid path. The signer pays for a bundle of signatures the resolver may never need. An IETF draft now proposes to stop sending the whole bouquet when one algorithm is expected to work everywhere.

The change matters to a domain using two DNS providers. In the independent-key model described by RFC 8901, each provider signs the same zone with its own keys. If they use different algorithms, the old all-algorithms rule can force them to coordinate a signature set neither naturally produces alone. A provider transfer has the same awkward interval. A root trust-anchor rollover can also require a long period of double signing before a new anchor is published. The draft wants to separate advance notice of a new trusted key from the immediate obligation to place its signatures on every answer.

The word “universal” has a bill attached

Draft multi-alg-rules-00 proposes a new IANA registry column called Validation support status. It would initially label algorithm 8, RSA/SHA-256, and algorithm 13, ECDSA P-256/SHA-256, UNIVERSAL. The choice is grounded in their present mandatory implementation status in the IANA DNSSEC algorithm table. A FORMERLY-UNIVERSAL label would mark an algorithm whose support has begun to decline; no algorithm starts in that class. Everything else has an empty value, described in the draft as NEVER-UNIVERSAL.

The proposed signer rule depends on the composition of the parent's DS records or the trust-anchor set. If that set contains at least one UNIVERSAL algorithm and no FORMERLY-UNIVERSAL algorithm, the signer must use at least one UNIVERSAL algorithm; other signatures are optional. The zone need only publish DNSKEYs for algorithms actually used to sign. If no UNIVERSAL algorithm is present, or any FORMERLY-UNIVERSAL algorithm is present, the old all-algorithms obligation remains. These are conditional rules, not a general permission to drop whatever signature costs money.

This buys operational freedom. Two providers using algorithms 8 and 13 could serve different valid paths without forcing each to sign with both. An operator could place a new trust anchor before the corresponding DNSKEY and signatures appear, then move when the new path is ready. The draft also points to experimental post-quantum algorithms: one provider could test an additional algorithm without making every partner in every multi-signer arrangement do the same overnight. A new algorithm that lacks UNIVERSAL status may still require a period of dual signing to complete a rollover.

The price is a stronger assumption about resolvers. Calling an algorithm UNIVERSAL means the zone operator can reasonably expect validators to implement it. The live IANA registry says algorithms 8 and 13 are mandatory to implement for validation; the proposed column would turn that expectation into a rule that changes what a signer may omit. A registry value becomes an operating dependency.

The resolver's local veto must carry its own label

Consider a zone advertising algorithms 8 and 13. One provider serves a valid path using 8. A resolver operator has disabled 8 locally but still supports 13. Under the draft's proposed validator rule, the resolver must treat that zone as unsigned rather than call the response bogus and return SERVFAIL merely because the served path uses the algorithm it chose to disable. The same treatment applies if a FORMERLY-UNIVERSAL algorithm is advertised but unsupported locally.

That is a striking allocation of responsibility. The signer followed a rule built on mandatory mainstream support. The resolver departed from that expectation. The draft makes the resulting loss of authentication a consequence of the resolver's policy, not an accusation that the zone operator served broken DNSSEC. The operator should see an insecure classification in monitoring and configuration records. A successful DNS answer alone will not disclose that the cryptographic check was set aside.

There is a reason the old all-algorithms rule existed. An attacker who strips the signatures a resolver can validate must not turn a previously secure answer into an apparently harmless insecure one. The draft argues that its UNIVERSAL and FORMERLY-UNIVERSAL classifications keep downgrade protection while permitting the lighter signature set. The promised protection rests on resolvers implementing those classifications correctly. The draft asks them to remember algorithms that once carried the universal designation, even after local support is switched off.

A long-lived DNSSEC migration therefore has two calendars. One belongs to the zone and its providers: DS publication, DNSKEY material, served signatures, trust-anchor staging and cache state. The other belongs to resolver operators: which algorithms remain enabled, which were once universal, and what security result they assign to each response. A signer can move perfectly on the first calendar while a resolver's unrecorded local switch changes the outcome on the second.

The public draft gives examples, not a measured population of affected zones or resolvers. The fact that would change an operator's rollout decision is an interoperability result across its real validating resolvers: do they return secure, insecure or bogus for each permitted signature subset and for an intentionally disabled universal algorithm? Without that matrix, “supports DNSSEC” is too coarse a claim for this transition.

The document is dated 31 October 2026 and remains an initial DNSOP working-group draft. No IANA Validation support status column appears in the live registry yet. Its political economy is already visible. A zone signer gains room to stop producing signatures merely to satisfy a hypothetical validator. A resolver operator who rejects a mainstream algorithm loses the luxury of blaming the zone when its own policy removes authentication. One signature may be enough; the person who turned off its verifier has to own the result.

IETF draft · RFC 4035 · RFC 6840 · RFC 8901 · IANA DNSSEC algorithms