Summary

  • IANA lists algorithm 18 as ML-DSA-44 and marks its signing and validation use MAY. The registry's EPP rule is the next gate for submitted DS data.
  • Joe Abley's RIPE 93 account and his October individual draft focus on that upstream gate: which DNSSEC algorithm and digest values registries and registrars accept in submitted DS data.

The number was there. The transaction could still stop at the next desk.

At RIPE 93 on 29 October, Joe Abley described trying to submit DNSSEC algorithm 18 through EPP. He said he had found no registry accepting it in the systems he had checked, then named one exception after a maintainer merged a code change following a conversation with Garth Miller. One coffee and one merge fixed one path. It did not create a policy other registries could predict.

The IANA DNSSEC algorithm registry now lists number 18 as ML-DSA-44. It allows the algorithm for zone signing and records MAY for use and implementation in signing and validation. Those fields record the allowed requirement level; deployment by registries, signers and validating resolvers is a separate operational state.

The EPP detail is small and consequential. RFC 5910 carries DS data through EPP. Its alg field names the DNSKEY algorithm referenced by the DS record; digestType names the digest used to make the DS. Abley's 14 October individual Internet-Draft targets those two fields. It proposes that registries and registrars use the IANA DNSSEC algorithm and digest registries as their shared rulebook, with exclusions for values that cannot provide DNSSEC security. Datatracker lists only individual version 00 at I-D Exists; the proposal has no IETF standards status.

That moves the control point into view. A signer can prepare a new algorithm, and IANA can assign it a number; the parent registry still decides whether the registrar may submit the DS. If that request fails, the child zone cannot complete the parent-side step of an algorithm rollover. A local allowlist that nobody publishes turns a standards transition into guesswork.

Acceptance and validation are separate decisions. A resolver that does not support an algorithm ignores its DS data. If no supported DS remains, that resolver treats the child as unsigned. EPP opens the submission path; resolver support is a separate deployment step.

The draft's policy-variation claim lacks a dated, registry-named compatibility matrix; publishing tested EPP values for each registry would establish its scale.

Primary records: RIPE 93 talk · RIPE 93 session transcript · IANA DNSSEC algorithm registry · RFC 5910 · RFC 4035 · Abley's individual draft, version 00.