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]
