There is a difference accepting any path and publishing zones that will FAIL TO VALIDATE AS SECURE OR INSECURE! DNSSEC was designed to fail insecure on old validators that didn’t support any of the algorithms. The rules that the signer needs to sign ALL records with ALL of the algorithms in the DS set is designed to prevent validators with a properly signed zone getting answers that validate as BOGUS! Signers which do not follow that rule WILL (100% guaranteed) produce zones that will produce answers that validate as BOGUS on some validators. The PROMISE we collectively made 20 years ago that if the signer follows these rules and you validate then you WILL NOT A BOGUS result. The whole multi-signer with signers that don’t support all algorithms is BAD engineering.
Now for PQ signing that uses multiple algorithms we can do that but by just hoping that the validator has all algorithms involved or none of the algorithms involved to sign the zone is not the way to go. We MUST assign a DNSSEC algorithm code point for that algorithm pair and it MUST be published in the DS RRset. This tells the validator unless it supports that algorithm pair that it should treat the zone as insecure. Additional I would use DNSKEYs with that code point and use the first byte of the key field to identify which sub algorithm it represents. I would also similarly identify the RRSIGs. Mark > On 26 Jul 2026, at 03:21, Johan Stenstam > <[email protected]> wrote: > > Somewhat late to the party, but better late than never. I fully agree with > everything in Libor’s response below. I think that this is an important > document that really ought to move forward. > > In addition to its importance for multi-signer and simplification of > algorithm rollovers it should be added that if this document was to be > standardized it would enable PQ-DNSSEC zones to use a strong PQ-safe > algorithm like ML-DSA-44 while using a small-signature algorithm for the rest > of the zone. While we don’t have any standardized PQ-safe small-signature > algorithms today this document is still an important prerequisite to being > able to use them when they get standardized. > > Finally, a very important property of this proposal is that it is easy to > deploy, because RFC6840-compliant resolvers (i.e. all resolvers) already > support this. I.e. to deploy a zone using multi-algorithms only require > control over the signer (easy) and the authoritative servers (also easy). The > part that are not under the control of the zone owner (the resolvers) are > already done. > > Johan > >> On 22 Oct 2025, at 11:37, Libor Peltan >> <[email protected]> wrote: >> >> I'm full supporting this document, as it clarifies the grey area between >> "validators MUST take any valid path" and "signers MUST sign will all >> algorithms in DS set", and simplifies algorithm roll-over, while enabling so >> far impossible operational modes like different-algorithm multi-signer. >> >> Regarding the specific "TL;DR" motivational section, I consider it >> comprehensible and helpful. >> >> I'm looking forward for this document to move forward. >> >> Libor > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
