Fun. I would prefer a version that also applies to stub-resolver queries. That would require some adjustments to the design but I think it's achievable. My preference would be: * The response can say "yes, but here are the new TTLs". * No LARGE. The client can embed a hash of the previous response (excluding TTLs), and the sender can truncate the response if the hash matches. This allows a stateless server implementation, allows resolvers to participate even if the auth server does not, and ensures that the response size never increases.
(This does create some interesting privacy concerns, but I thinks it's OK.) --Ben Schwartz On Thu, Jul 2, 2026 at 12:34 PM 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nothing-new/__;!!Bt8RZUm9aw!4bGm3VE9tB6s0Yv3Yzs053DutbGYTfTDS7eLriiYO4C9wCuJl_kUCM52UnSL7HEh62jjgJ2D7JTEHg$ > > 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]
