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.

> > 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.

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.


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

Reply via email to