In our experience, operators ask for temporary NTAs not because they
don't value DNSSEC validation, but because they need operational tools
for the occasional DNSSEC incident. Without those tools, subscribers
often perceive the ISP resolver as unreliable and either operators
resort to forwarding specific domains to public resolvers, or
subscribers configure public resolvers directly in their CPEs or
devices. In either case, the ISP loses the ability to provide RPZ,
malware filtering, parental controls, and other local protections.
-Carlos
On 20/07/2026 10:14, Mukund Sivaraman wrote:
On Mon, Jul 20, 2026 at 03:35:03AM -0400, Paul Wouters wrote:
Bas wrote:
If we care for PQ DNSSEC by 2031, what would be the most practical path? We
can't be too ambitious.
So what are we looking at? The only practical [1] signature scheme available on
this timeframe is ML-DSA-44 with 2,420 byte signatures and 1,322 byte public
keys. We can't have authoritatives include these by default: it'll break
clients that can't fall back to TCP, or are buggy in other ways.
Bas: By clients that can't fall back to TCP, do you mean clients that
don't implement TCP or can't use TCP in their network? Assuming this is
primarily a validating DNS client such as a validating resolver,
wouldn't it suffice to think that it ought to be able to use TCP?
If it's that answer + RRSIG RRsets ought to pass over UDP to a client
that's not a validating resolver which queries for it and it can't pass
over UDP, it'll get a response with TC=1 for DO=1 and won't be able to
query it over UDP. But can this not be considered negligible considering
the client can't do UDP and it's not going to be validating? RFC 6840
allows AD flag signal in the response if the query has AD=1 even if
DO=0, so a client that can only use UDP and wants just the answer but
also wants to know if it is authenticated can still get just that signal
in the AD bit without any of the RRSIGs, and the validation happens on a
resolver that's capable of TCP.
This assumes we are stuck with the current transport. The real question
is, should we fix the tranport so we then no longer care about size of
signaures, or should we limit the new PQ crypto based on the current
packet size issues. I feel it might be better to think of a DNS protocol
fragmentation support so that from a DNS protocol point of view, we can
just send huge packets.
Many years ago, Shane and I came up with
<https://datatracker.ietf.org/doc/html/draft-muks-dns-message-fragments-00>
but it didn't go anywhere.
Thinking of this today and reading some of the other proposals, I am
less fond of introducing hacks in DNS protocol and prefer elegance
that's available (such as the TCP stream). As someone else pointed out,
one day it'll also be the DNS message's 64kiB size's time but perhaps
we're not there yet.
Mukund
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
