[DNSOP] Re: [Ext] An unofficial DNSSEC algorithm testing registry

On Jun 26, 2026, at 14:29, Johan Stenstam <[email protected]> wrote:
> 
> Hi Paul,
> 
>>> 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.
> 
> Ok, fair enough. But that’s only because there *isn’t* an experimental range, right?

Not only that, no. Given the problems that other groups have had well-documented problems with experimental ranges (code $experimental1 is used for FALCON testing, later FALCON is assigned code $real1, now developers have to guess how long to keep using $experimental1), we think that using 253-with-lead-in is actually better for the community.

> 
>>> 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.
> 
> Sounds like we should do more experiments with both, doesn’t it?

Yes, definitely.

> 
>>> 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.
> 
> I disagree that this is only valid for ML-DSA, but this is not the time for debating one algorithm against another.

Agree. FWIW, it's not only valid for ML-DSA: there are other signature algorithms that could have the same size properties but other properties that DNSSEC might like. We won't know until there is more grinding experimentation.

>>> 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.
> 
> That really depends on what you’re testing.

I'm not sure what you mean here; please say more.

>>> 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.
> 
> No offense, but that’s a kludge.

Correct, and I apologize for not being clear. I should have said "Our registry requires a different type of kludgery that we believe is easier to implement now and causes less long-term problems for implementers."

> 
>>> 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.
> 
> I agree with Joe’s assessment: this sounds like “the process is complex, let’s avoid the process”.
> 
> I happen to agree that the process is complex (in the sense of being very time consuming), but my take is that we should instead then try to fix the process.

That delays the testing by a long time, possibly a year, and a lot of process effort by a lot of people. You might want to do that at the same time we are already doing the needed testing.

> We have had repeated discussions about “fast-tracking” drafts that are sufficiently simple (but relevant). I think this is a perfect example of such a case: 
> 
> * there seem to be quite wide agreement that we need to facilitate more experimentation with a whole bunch of PQC algorithms and that the current mechanism (the 253/254 code points) are not sufficient

We disagree with that.

> 
> * there is a formal proposal that we allocate a range of DNSSEC algorithm code points for this

Yes.

> If no one objects and we all agree that it is a bit urgent, then exactly what is stopping WG adoption and then a WGLC soon thereafter?

That's a question for the WG chairs, the ADs, and the IESG.

> 
> If, on the other hand, this boils down into an endless discussion, then I was wrong and will have to agree that the process is too complex.

I hope you're wrong. I just want to be able to do useful testing while you find out.

> 
> That said, here is a suggestion for a compromise:
> 
> * Let’s start the formal process for allocation of an experimental range of algorithm code points ASAP.
> 
> * Meanwhile we create an informal registry (like the one Duane and you have created) for *coordinated* code point squatting at the same range that the proposal suggests.

Please stop using the pejorative word "squatting". Our registry uses an existing code point in the way it was specified long ago.

> 
> * The informal registry should also have a hard latest termination date and be terminated at the earliest of (formal process complete, hard latest termination date).

We should certainly look at terminating the registry if the formal process completes and the experimental codepoints in that registry become useful. 

--Paul Hoffman


_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]