Timing is everything. Duane and I were *just* about to post the following when we saw Johan's new draft. We think our solution takes a lot less group work and gets almost the same results for DNSSEC implementers who want to test new algorithms. Please see: https://github.com/wessels/dnssec-algorithm-testing-registry
In short, the IETF or IANA don't need to do anything to allow DNSSEC algorithm testing among implementers. We wanted to create the lowest-overhead solution that causes the least long-term headaches for the DNS. Simply look in the registry at that repo, and if you want to specify a new algorithm, send in an issue or pull request. Using an unofficial registry of algorithm 253 values avoids an eventual transition from an "experimental" to value to the real one. It also allows multiple definitions of experimental algorithms, which will be needed because some desired algorithms are still changing. See below for my response to Johan's proposal. (And a hat-tip to Wes and Ondřej who individually suggested the need for algorithm testing after a frustrating meeting we were in last week. Those requests were what nudged this solution.) --Paul Hoffman and Duane Wessels On Jun 25, 2026, at 12:08, Johan Stenstam <[email protected]> wrote: > The problem that the only “experimental use” DNSSEC algorithms are the > multiplexed 253+254 code points that have unique constraints on how they can > be used has been discussed repeatedly. And the problem simply doesn’t go away. Definitely agree. > Furthermore, the problem is becoming more acute, because we really need to > start experimenting with various PQ-safe algorithms Agree. > and without an allocated experimental range we will all do code > point-squatting at random which certainly doesn’t help with experiments and > testing. Fully disagree. We use 253 with a lead-in three bytes and an completely informal registry. > In addition to that there are a couple of other reasons why this is becoming > important. > > One rather promising idea that has come out of the various PQ-DNSSEC > experiments that we’re doing right now is using the algorithm number in the > parent-side DS RRset as a signal (to the validator) that the DNSKEY RRset is > likely to be large and that querying for the DNSKEY RRset over UDP should not > even be attempted. That is one proposal for reducing a constant stream of UDP-whoops-TCP sessions. Another proposal that I have heard is resolvers keeping a cached list of UDP queries that went to TCP, and just starting on TCP the next times. That cache can be timed out every few hours. > Example: if the alg number in the DS represents ML-DSA-44 (~1300 byte public > key + ~2.5 KB signature), then a validator that understands which algorithm > numbers represent “large” DNSKEY RRsets can avoid the costly UDP roundtrip. > And as queries for DNSKEYs are likely < 0.1% of all queries in most cases, > the PQ packet size problem has suddenly shrunk. True, but this is only valid for ML-DSA. There still seems to be a lot of interest in FALCON (897 byte public key, 666 byte signature), even though its eventual standardization status as FN-DSA is unclear. For FN-DSA, single-signature responses don't fall back to TCP, but NXDOMAIN responses that have three signatures do. > But it only works if we use distinct code points for different algorithms. This is true for deploying the real algorithm, but isn't necessary for testing. > It is also one thing to experiment with a single new algorithm (and then use > 253 or 254). But in the PQ space there are *many* algorithms. In our name > servers we currently do testing with 15 different algorithms (4 * MAYO, 2 * > FALCON, 3 * SNOVA, 3 * ML-DSA, SQISIGN, SLH-DSA-128s and one of the QR-UOV > algs). The amount of kludgery that would need to be added to the code by not > knowing what algorithm it is until the DNSKEY has been fetched, an identifier > string has been extracted from the public key and mapped against the > algorithms that the code even knows how to use is not reasonable. So we do > code point squatting instead, which makes collaboration with others much more > difficult (see above). Our registry requires no such kludgery. You look at the first three bytes of the DNSKEY or RRSIG: if the first byte is 0x01, and the third is 0x00, you know it might be in the unofficial registry. > AFAIK no one is implementing tests and experiments with algorithms that do > not have official IANA codepoints via the 253/254 special hacks. Everyone is > doing random squatting instead -- at exactly the time when we should be > making testing and experimentation as easy as possible, given the shrinking > window we have to get PQ-safe. Quite true. That's why waiting for a draft to be adopted by the DNSOP WG, passed through the process, and then getting IANA assignments will delay testing that we know is being done now. Our very informal registry is up and happening today. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
