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]
