[DNSOP] Re: Thoughts on handling large RRset sizes with PQC and other datasets
Carlos Horowicz <[email protected]> Tue, 7 Jul 2026 11:54:57 +0200
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
As DoQ deployment increases, DNS becomes less constrained by the traditional limitations of DNS over UDP. Combined with DPLPMTUD, that may gradually reduce the pressure to optimize DNSSEC solely around response size, while TCP remains a perfectly viable fallback. —Carlos On 07/07/2026 09:32, Joe Abley wrote: > On 7 Jul 2026, at 07:02, Ondřej Surý<[email protected]> wrote: > >> I believe it is dangerous to say "it is ok to deploy PQC algorithms with >> large signatures" because we have these optimizations. The fact is >> that we either need a PQC algorithm that will be size-suitable for DNS >> or we will have to brace for the impact of completely switching to TCP. > I think this idea (Wes' idea) is interesting but I think we are again just moving deckchairs. We could keep bolting on new bracing to prolong the life of UDP transport, or we could just concentrate our efforts on the inevitable widespread option of something better. > > We have secure, stream-based transport defined and in use between stub and resolver. It doesn't take too much imagination to see those transport protocols being used in other parts of the resolution graph, with port 53 relegated to legacy support for a long tail of clients that will probably never be able to consume a PQC signature. > > I don't think there is any chance of DNSSEC meeting any of the PQC deadlines we know about. However, PQC is already deployed and in use in TLS. The encrypted transport protocols already defined and in use in the DNS use TLS. > > We should concentrate our energy on connecting these dots. > > > Joe > > _______________________________________________ > DNSOP mailing list [email protected] > To unsubscribe send an email [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]