> On 11 Nov 2025, at 02:15, Philip Homburg <[email protected]> wrote: > > In your letter dated Mon, 10 Nov 2025 09:42:35 +1100 you wrote: >> So you want all experimentation to be done on closed networks an >> algorithm at a time? > > Using a private space on the public internet always has a bit of a risk. > I assume that DNSSEC validators are robust enough that they won't fall over > if they encounter something weird. So I don't see the need for > closed networks. > > I don't know where the one algorithm at a time comes from. I'm perfectly > fine with using PRIVATEDNS. I just don't want to update the hash functions.
No one is asking you to upgrade hash functions. What we are asking for is new code points for 3 of the existing algorithms which indicate additional functionality. It you are using PRIVATEDNS or PRIVATEOID you use the new code points for PRIVATEDNS and PRIVATEOID DNSKEYS. If you don’t support PRIVATEDNS or PRIVATEOID there is no need to do anything. If there is ever a new algorithm then you need to add code to look at the start of the hash if you support PRIVATEDNS or PRIVATEOID. Now if we make it that you MUST use a DS type that embeds that PRIVATE algorithm for PRIVATEDNS and PRIVATEOID the validator can just skip DS records for PRIVATEDNS or PRIVATEOID DNSKEYs that don’t use the new code points. >>> I don't understand what you are trying to say. My point is that this draft >>> adds too much complexity to participating in PQC experiments. >> >> It actually reduces the complexity of the validator. As things >> stand when you have DS rrset you have to defer the determination >> of whether you support the algorithm until you have a copy of the >> DNSKEY rrset. That may involve doing an additional fetch to retrieve >> the DNSKEY rrset if it is not already cached. Now the latest >> versions of named does this but this would not be necessary if the >> DS records contain the private algorithm identifiers. > > You say 'have to defer'. That is not have to. It is also possible to > not defer and accept the possibility that you sometimes get a DNSSEC > validation error. Actually you have to if you implement DNSSEC and support PRIVATEDNS or PRIVATEOID. If you are not implementing DNSSEC then you can do what you want but don’t claim your code is DNSSEC compliant. > If the goal is to avoid validaton errors during an PQC experiment, then > draft-yorgos-dnsop-dry-run-dnssec is a much more interesting alternative. My goal is to be able to use PRIVATEDNS and PRIVATEOID DNSKEYs in all the scenarios that you can use other DNSKEYs. This is not currently possible. -- 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]
