[DNSOP] Thoughts on handling large RRset sizes with PQC and ot her datasets

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]