On Tue, Nov 11, 2025 at 10:17:44AM +0100, Philip Homburg wrote:
> I'm looking at it from the point of view of implementations that currently
> have no support for PRIVATE* but may get used for PQC experiments.
>
> Adding new DS hash functions that need to be implemented by those
> experiments does not help for that use-case.
An associated tweak to the DS RDATA does not seem like a major barrier
to experimenting with new PQC DNSSEC algorithms. Especially since in
another post you suggest that DS RRs are not needed for the experiments
at all, since as part of an experiment presumably one might just require
the appropriate DNSKEYs by local policy for the domains in question.
But if, as part of testing new PQC algorithsm, one really does want to
exercise the full DNSSEC state-machine, including use of DS RRs for
downgrade-resistant signalling of support for particular algorithms,
then Mark's proposal seems to make sense, and does not appear to impose
any burden on implementations that don't support PRIVATE algorithms.
What the proposal does do is reduce opportunity for confusion when
multiple experiments are in progress with private code points in the
public DNS.
If this had placed a burden on production implementations, I'd also push
back, but since it affects only bleeding-edge experiments, it seems
reasonable to make DS RRs be unambiguous.
Elsewhere in the thread, there was mention of leveraging the keytag in
the DS to find the corresponding DNSKEY RR, (presumably also checking
for a hash match) and then extracting the algorithm ID from that.
Perhaps that alternative deserves further discussion:
- My model of robust DS RR publication practice is that each
published DS RR should always match an extant DNSKEY. That
key should be in place sufficiently far in advance of the DS
publication, and be removed sufficiently long after the DS
removal.
- Unless there are compelling reasons to violate the above
"invariant", perhaps the algorithm IDs in the required matching
DNSKEY are sufficient? In which a private DS obligates the
zone to have a matching (by tag and hash) DNSKEY in order that
implementations that do support private algorithm code points
be able to properly associate the DS RR with the right algorithm.
Otherwise, if for some reasona the "invariant" above is not viable,
then the private DS RRs can be made self-sufficient per Mark's proposal.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
