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

Petr Špaček <[email protected]> Tue, 14 Jul 2026 15:20:19 +0200
Newsgroups gmane.ietf.dnsop
Message-ID <[email protected]>
On 27. 06. 26 14:28, Philip Homburg wrote:
>> 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.
> 
>>From a developer point of view, this is exactly the same problem. For the
> question how long to support $experimental1 it doesn't matter whether it is
> an expiremental code point or a third-party registry built on top of a
> an extension mechanism for private algorithms.

I think the fundamental problem is: The registry range is too limited so 
we need to care.

If we had registry and 32 bit value with FCFS allocation policy, we 
could just allocate a new algorithm number every week and still have 
plenty. And if the algorithm did not took or/was retracted by NIST, who 
cares, just leave the number in there and move on.

253 and 254 can do the same but have their own quirks which are people 
seemingly unwilling to fix.

Would it help if we extended the range by allocating one value which 
says 'EXTENDED-ALGORITHM' followed by 4 bytes unsigned int, which would 
be present in DNSKEY/DS/RRSIG payload?

Should be simple enough if people are actually willing to do any work at 
code at all.

-- 
Petr Špaček

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