> This draft explores an additional mechanism to solve #3 by further > reducing the quantity of large packets needed to be sent. It does > this by indicating that no changes have been made to DNS records, > which would otherwise be large and a burden to transmit frequently.
Hi Wes, it is important to emphasize that your proposal is just an optimization and it offers no added protection to reduce the extra traffic. Currently, the Security Consideration section discusses just the impact of MitM spoofing, but it misses the new attack surface (which is common to other mechanisms to reduce the network traffic and the amount of TCP needed). The malicious server can just say "nope, this is new". Combine this with PRSD attack and the resolver is back to square one. E.g. your proposal requires everyone to behave. This is often not the case on the Internet. 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. Ondrej -- Ondřej Surý (He/Him) [email protected] A gentle nudge is always appreciated if I take a little longer to reply. > On 2. 7. 2026, at 18:32, Wes Hardaker <[email protected]> wrote: > > > The DNS world is a bit behind in thinking about the impact of PQC > algorithms and their impact on DNSSEC. That's not being quite fair, as > there have been a bunch of people doing research and pointing out the > issues are pressing and difficult. But few solutions exist other than > "just use TCP". > > So I was thinking about that problem space and how to continue being as > efficient as possible without requiring every connection be over TCP and > every connection always downloading large RRsets. And during thinking > about that, the bad idea fairy paid me a visit. So I wrote down the > whispers from the fairy that entered my ears: > > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nothing-new/ > > This is more hoping to start discussions and thinking more than > believing this is the perfect solution (as it's a hack, though the more > I've thought about it the happier I've become with the hack). > > Thanks and sorry, > Wes > > --------------- > > I'll include the relevant set of introduction text here for ease: > > 1.1. Background > > The DNS protocol has increasingly needed to carry larger records than > it was originally designed to carry. This has resulted in > performance impacts due to both the size increases and requiring TCP > instead of only UDP. Of particular note is the expected large > increase in records relating to Post-Quantum-Computing (PQC) signing > algorithms. Note that while this draft concentrates on PQC > algorithms, the techniques proposed should help mitigate other large > packet size issues with any types of DNS data. > > With the increase in size requirements being transmitted over DNS, we > have but a few options to address the need for large RRsets and/or > mitigate the burden on authoritative servers. These are at least > some of the options available: > > 1. Encourage the switch to TCP for requests which are known to > generate large responses. Especially those performing DNSSEC (DO > bit) queries. > > 2. Investigate and deploy DNSSEC signing algorithms and deploy that > minimize the packet size impacts. We have already done this > recently, to some extent, with the shift to elliptic curve based > algorithms in DNSSEC > > But PQC algorithms will be significantly larger, even if we > standardize on an algorithms with the smallest key and signature > sizes. > > 3. Reduce the need for sending large responses in the first place. > The most obvious solution to this is to increase TTL values. > However, that is not always possible. > > This draft explores an additional mechanism to solve #3 by further > reducing the quantity of large packets needed to be sent. It does > this by indicating that no changes have been made to DNS records, > which would otherwise be large and a burden to transmit frequently. > > 1.2. Technique Overview > > This document proposes a new "nothing new" NN flag, a LARGE > Redirection Resource record type, and describes how these can > integrate with current and future DNSSEC DNSKEY and RRSIG records. > > This document proposes two technical mechanisms for signaling that > resource records have not changed since a previously obtained set, > and thus do not need to be re-fetched. This potentially saves > significant resources on both the client and server. These > optimizations include: > > * A new Nothing New (NN) DNS bit, to be used in conjunction with the > Truncated Response (TC) bit that indicates the requested records > have not been changed recently, and thus cached data is sufficient > fro use. See Section 3 for details. > > * A LARGE resource record (Section 4) that serves as a hint about > what version of a record is current and whether or not a client > needs to refetch its contents. > > The trustability of these unsigned signals is discussed in Section 6. > > The simple goal of these new features is to reduce the necessary > number of large responses from authoritative servers when > communicating with conforming resolver clients. Effectively, these > mechanisms allow for signaling both: > > 1. If a recursive resolver has data in its cache, it may keep using > it (assuming the cached DNSSEC signatures are still valid if it > is validating). > > 2. A version number of the data requested to check against a > resolver's cache, providing a hint about whether the data in a > resolvers cache is actually old or the same. > > -- > Wes Hardaker > Google > > _______________________________________________ > 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]
