Hi Bas Consider the following optimization to save an otherwise wasted UDP query, TC=1 response exchange:
A resolver receives the DS RRset for a zone as part of the delegation
response, that contains algorithm numbers of the DNSKEYs in the child
zone. From that it has a hint that large sized signatures and keys are
possible in the child zone with truncation likely, and it could avoid
UDP first and directly use TCP saving an extra roundtrip.
I noticed this also in the security considerations of the MTL draft:
> Clients concerned about re-tries, e.g., a UDP query being truncated
> and then re-attempted over TCP, are RECOMMENDED to perform all queries
> over TCP when encountering a zone signed with ML-DSA-44-MTL-SHAKE-128.
Some things to consider:
* The DS RRset in the delegation response is not validated by some
resolver implementations at that point before the resolver contacts
the next nameserver. It's cached with trust pending for validation
later. So using the content of an unvalidated DS can be considered an
opening for mischief, but it does not affect DNSSEC security. Consider
that the NS RRset and any glue that the resolver will chase is not
validated either, and only a hint of whether to use TCP for transport
selection is gathered from the DS RRset.
* A validator is more liberal in what it can accept compared to what a
signer can produce. Some cases are possible due to transient
inconsistencies, or misconfiguration, or just non conforming singing
where there are multiple algorithms in the DS RRset (e.g 13+18), but
an RRSIG in the child zone is only signed with one (e.g. 13) which
means that such a response could carry over UDP without truncation if
it's signed with classical algorithms. In this case, the speculative
use of TCP may be detrimental. But this is a corner case. Downgrade
protection also enforces the PQ algorithm.
Another approach may be maintaining state if a zone consistently
requires TCP. But if using the DS hint directly is reasonable, that may
perform from the initial contact.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
