[DNSOP] Re: PQ DNSSEC?

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]