[DNSOP] Re: Thoughts on handling large RRset sizes with PQC and other datasets

Hi Wes et al....

I've recently also begun thinking about this problem, and I think you're 
missing a 4th option - reframe the problem to fit the existing tech.

One problem exacerbated by DNSSEC is the Lay's Conjecture:  "You can't 
eat just one" - if there is more than one record in an RRSet, you can't 
choose just the one you want/need to download.

Proposition:

1) Create a DNSKEYHASH record - basically one per signed zone that has 
as its contents most of what goes into the DS record for each of the 
keys in the label's DNSKEY RRSet.  Also, some metadata about key 
lifetime and key size - to indicate upfront whether or not TCP will be 
required.
2) DNS database and query aliases for each of the DNSKEYs at 
<tag>.<algorithm>.<dnskeyrrtype>._alias.<label>.<zone>
3) DNS database and query aliases for each of the RRSigs (for any RRSet) 
at <tag>.<algorithm>.<rrtype>._alias.<label>.<zone>
4) an EDNS0 flag that indicates that the zone supports aliasing
5) a DNSKEY flag that indicates the key and its signatures are aliased 
in addition to any availability at the normal spot


That gets you to:

  * Each query to an alias location gets only a single record.
  * A DNSKEY is valid if and only if a) HASH(DNSKEY) == one of the
    records in the DNSKEYHASH record and b) the signature over the
    DNSKEYHASH record chains properly.
  * All the existing records remain behind allowing for a graceful
    implementation and eventually a transition.
  * There is incentive for clients to change to the new retrieval model
    in that it substantially reduces the time they need to download keys
    and signatures.
   * From a server side point of view, theses are  name aliases into an
    RRSet so additional storage should be minimal.  This is just
    translating a query into a record lookup.
  * None of the alias RRSets get signed.  Only new signature(s) is the
    one over the DNSKEYHASH.
  * Unclear if aliasing should be extended to other RRSet types.

I'm sure there are/will be issues with the above, but getting things 
down to a place where I don't have to retrieve ALL the DNSKEYs and ALL 
the RRSIG(foo) records to verify an RRSet seems to be a good first step.

And... discuss!

Later, Mike







On 7/2/2026 12:32, Wes Hardaker 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.
>

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]