The 126th meeting of the Internet Engineering Task Force (IETF) was held in Vienna at the end of July 2026. It was a busy week, with many meetings and conversations. These are some notes from Domain Name System (DNS)-related sessions that I found interesting. I’ll dive into a select set of presentations and topics in some depth, avoiding brief summaries and generalizations if I can!
Recursive resolver DNS query behaviour
If you look hard enough, you will likely find anything you want in the massive and diverse world of the DNS. In this case, the Internet Systems Consortium’s (ISC’s) Ondřej Surý examined the query behaviour of a recursive resolver when started with a cold cache and given a name to resolve. His startling example was an IPv6 reverse name where the query was for the pointer (PTR) record. It took BIND 2.18 a staggering 329 queries to resolve! Not all queries are as complex as that, but when there is no pre-warmed cache, then you get to see the inner workings of the way a resolver navigates its way through the DNS space to establish the ‘right’ nameserver to query.
Several factors contribute to this query volume, including the number of delegation points in a DNS name, the use of out-of-bailiwick nameserver names, the use of canonical names (CNAMEs), and the addition of DNS Security Extensions (DNSSEC) validation. There is the additional factor of apparently unrelated DNS names drawn into a network of implicit trust that expands the resolution workload. The correct resolution of a name can rely on the correct resolution of many other names. A good example is www.example.com, whose full resolution set of paths is shown in Figure 1.
www.example.com from the Transitive Trust Checker.For a ‘cold start’ resolver, resolution of this name requires:
- A priming query for the root zone.
- A query to a root zone server for a
.comserver. - A query to a
.comserver for anexample.comserver. - A final query for the terminal name.
That’s four queries, meaning that a resolution procedure is trusting four points in the DNS. Right?
Well, yes and no.
There are thirteen named root name servers, and you cannot tell in advance which of these names will be used in the resolution process — so you are in fact trusting all thirteen! The same applies to the thirteen nameservers for the .com Top-Level Domain (TLD). Furthermore, the web of trust is even larger because the nameservers for the root zone reside in the .net TLD, meaning you must trust all those servers as well. The full picture of trust points for this simple name can be seen in Figure 1.
Then there are so-called glue records. For example, if a recursive resolver has not yet established the IP addresses for the .net zone nameservers, who can it ask to resolve the name a.gtld-servers.net? This circular dependence cannot be resolved without additional assistance. In this case, the DNS response providing the .net nameservers also includes an additional section containing the IP addresses of those named nameservers, the glue records.
In cases of circular dependence, a recursive resolver is forced to trust them to complete name resolution. Earlier DNS practice was to include these glue records for all nameserver responses, allowing recursive resolvers to use them as a convenient shortcut even when no circular dependence existed. It did not take long for this to be abused, giving rise to ‘DNS cache poisoning‘, where false glue records are injected into DNS responses to misdirect resolvers. Today, resolvers are supposed to enforce a strict in-bailiwick condition to trust and use glue records, meaning the nameserver’s name must lie within the zone of the name being resolved for the glue record to be used.
Then there is DNSSEC. So far, DNSSEC does not add heavily to the initial query load required to resolve a name — though current IETF work on DELEG records may throw a hefty spanner at that claim! However, validating the DNS response may entail further queries for the Delegation Signer (DS) records throughout the parent chain of the name being resolved.
CNAMEs are also very popular in the Content Distribution Network (CDN) world of outsourced web hosting. They allow control to be redirected across single DNS labels in ways that would otherwise be impossible. For a cold-state DNS resolver, this context switch can trigger an entirely new sequence of queries. For instance, resolving teams.microsoft.com causes a resolution operation in the .com domain to trigger a secondary resolution in the .net domain:
$ dig A teams.microsoft.com @localhost
; <<>> DiG 9.20.24 <<>> A teams.microsoft.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47975
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: c22c76c27093d61e010000006a5dbec6d3caeadfb3d848fe (good)
;; QUESTION SECTION:
;teams.microsoft.com. IN A
;; ANSWER SECTION:
teams.microsoft.com. 259200 IN CNAME teams.office.com.
teams.office.com. 300 IN CNAME tmc-g2.tm-4.office.com.
tmc-g2.tm-4.office.com. 60 IN CNAME teams-office-com.s-0005.dual-s-msedge.net.
teams-office-com.s-0005.dual-s-msedge.net. 240 IN CNAME s-0005.dual-s-msedge.net.
s-0005.dual-s-msedge.net. 240 IN A 52.123.129.14
s-0005.dual-s-msedge.net. 240 IN A 52.123.128.14In this case, microsoft.com has some challenges with out-of-bailiwick nameserver names:
$ dig NS microsoft.com
; <<>> DiG 9.20.24 <<>> NS microsoft.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21986
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;microsoft.com. IN NS
;; ANSWER SECTION:
microsoft.com. 2374 IN NS ns3-39.azure-dns.org.
microsoft.com. 2374 IN NS ns4-39.azure-dns.info.
microsoft.com. 2374 IN NS ns1-39.azure-dns.com.
microsoft.com. 2374 IN NS ns2-39.azure-dns.net.All of this presents some tough choices for DNS resolver design. There is the ‘resolve everything’ approach, where at every delegation level, the resolver resolves the names of all nameservers lying outside the strict in-bailiwick names. While thorough, this exposes the resolver to high query loads, and malicious actors can contrive name structures that trigger intense workloads.
Alternatively, ‘selective resolution’ has the resolver pick a single nameserver at each level, resolve that name, and use it for subsequent queries. This operates efficiently if the selected nameserver is responsive. However, if the selected server fails, falling back to a different nameserver can force a full resolution operation.
Ultimately, resolver behaviour is the result of applying a given name configuration to a resolver engine. The engine can be tuned to optimize performance or increase resilience against cache poisoning, but contrived configurations can still place a heavy burden on resolvers.
Fortunately, the situation is not completely hopeless. Implementing a few straightforward strategies can help improve performance and stability:
- Domain operators should prefer in-domain nameservers for delegations whenever possible.
- If they are using a managed DNS provider, they should pick two at most, as adding more only incurs cost without offering marginal benefits.
- They should avoid long CNAME chains where possible, as every CNAME acts as a new resolution operation.
- Recursive DNS resolvers should use aggressive NSEC caching where possible.
Querying the child side of a delegation solely to validate a zone’s nameservers has a dubious cost-to-benefit return, and pre-resolving all nameserver names before processing creates work with very little realized benefit.
Don’t forget that the DNS only really works because of local caching. This exercise in looking at a DNS recursive resolver’s behaviour with a completely empty local cache is a contrived situation. Yes, there are perfectly valid reasons why some names and zones use short Time to Live (TTL) values, but if no such reason exists, then don’t do it! It makes sense to use cautious configuration planning, with longer TTLs for DNS records to maximize the utility of a resolver’s local cache.
Slides: DNS, Transitive Trust and How Many is Too Many, Ondřej Surý, IEPG Session
Post-quantum DNSSEC
It seems odd to be considering the options for a technology that is largely a deployment failure so far, namely DNSSEC, when contemplating the impact of a radically different model of computing that is a wild-eyed punt on a madly experimental esoteric future technology that may or may not get anywhere useful, let alone affordable as an accessible technology.
It’s challenging to take quantum computing seriously when the current landmark achievement of quantum computing is to find the prime factors of 35! Any consideration of the capabilities needs to take a gigantic leap in the direction of suspending disbelief!
On the other hand, to look at the germanium transistor of 1947, and forecast that within 80 years we would see the mass production of silicon chips with close to a trillion of these silicon gates on each chip, operating with clocks that run at a frequency of gigahertz, would’ve been equally challenging. Similar feats of rapid spectacular innovation have happened in recent times. It’s not clear that we should take post-quantum (PQ) DNSSEC seriously today, but equally it’s unclear just how foolhardy we’d be if we ignored it!
I would add a second aspect to the commentary on Post-Quantum Cryptography (PQC) with respect to the DNS, and DNSSEC in particular.
The concern is the potential ability to break the key used to encrypt the data or generate the digital signature within the lifetime over which you would like the data to remain protected. In the case of transport layer encryption, for example, you may want the data to remain a secret for, say, twenty years, in which case your concern is the ability to break the key over the next twenty years.
But that’s not how the DNS works.
The interlocking key structure means that a key is no longer useful once it has rolled. The time to be really concerned about PQC in the DNS is when the lifetime of your key material falls within the horizon of a quantum-capable computer. If you are using 20-year key lifetimes, then there is a good case to be made that you should be concerned today. But right now, the most effective way to mitigate your DNSSEC cryptography concerns is to reduce the key lifetime, not to deploy PQC.
While suspending even more disbelief about the immediate relevance of this topic to DNSSEC, let’s head on into this topic.
How can we tweak the DNS to be more resilient to PQ computer capabilities? So far, all I have heard over some years now are some extremely ordinary ideas about stuffing large data sets into DNS responses and the need to switch away from User Datagram Protocol (UDP) to some Transport Control Protocol (TCP) style transport that can handle large payloads.
There are also some slightly more innovative concepts such as fragmentation at the DNS application layer rather than at the IP or transport layer that might be able to preserve much of today’s UDP transport. The conclusions appear to be that we can do this if we must with today’s DNS infrastructure. And we can tweak things a little to make this slightly less onerous than otherwise.
But compulsion is not the same as unconstrained choice. Can we afford to do this everywhere, all the time? The DNS is incredibly small, lightweight, and cheap! DNS queries (and responses) are free because their marginal cost is microscopically small in today’s network. The problems with these ‘DNS with large payload’ ideas are not due to their technical infeasibility — far from it — but because they are fiscally unaffordable in the current framework of the economics of the DNS! You can do it, but if everyone did it, then we couldn’t afford it!
There are other approaches that DNSSEC can use to defend against a quantum attack, and I was very interested in a presentation to the PQ DNSSEC side meeting by Johan Stenstam, who presented on three PQ-DNSSEC experiments.
The first experiment is based on the observation that Shor’s algorithm runs in polynomial time, specifically using operations, where N is the number being factored. The number of stable qubits available determines if the algorithm can run at all, not the length of time to execute the algorithm.
On a powerful, fault-tolerant quantum computer, factoring a 2,048-bit RSA key would take anywhere from a few hours to several days depending on hardware speed and physical qubit parallelism. Given this algorithm limitation, what if you rolled a DNSSEC Key-Signing Key (KSK) every 10 minutes? If it took way more than double that time to break the key, then this quantum capability would be useless to the attacker, as the DNSSEC key state has already moved on, and knowledge of an old, discarded key is not generally useful to an attacker.
In this case, Johan used DSYNC to signal a roll of an ED25519 KSK every ten minutes for three months. He did not pre-publish the DNSKEY, but did pre-publish the quantum-opaque delegation signer (DS) hash of the key. The central concept here is that by the time Shor’s algorithm operating on a cryptographically relevant quantum computer ‘breaks’ the KSK, the KSK has already been rolled.
Johan’s second experiment is based on the use of both the KSK and the Zone-Signing Key (ZSK). What if you use a large PQ algorithm for the KSK that signs a zone’s apex DNSKEY, and use a ZSK that has a far smaller signature? Such split-profile zones sign and validate normally — ordinary (ZSK-signed) signed responses stay within the bounds of UDP transactions and only the DNSKEY RRset is large. Given that it’s the ZSK signatures that are used for signed responses to queries, the larger DNSKEY is only exposed in validation queries.
This approach of a ‘strong’ PQ KSK with a smaller-signature PQ ZSK appears to represent a workable compromise between payload sizes and adequate cryptographic protection.
His third experiment, that of the ‘Gargantuan’ Combined Signing Key (CSK), is also interesting:
As Johan points out, the DNSKEY response is 23,843 bytes, and two 23K keys still fit in a DNS TCP response, as it’s less than 64K in size, so key rollover is supported. Yes, you need to patch the DNS implementation to use large buffers, then it ‘works like a charm’.
What is apparent at this stage is that the mono-algorithm approach used in DNSSEC to date is perhaps inappropriate for PQ DNSSEC. KSK and ZSK keys have different requirements. The KSK needs to prioritize long-term stability (to minimize interaction with the parent zone’s management of the DS records) versus smaller signatures in the ZSK rolled at a far higher frequency to maintain viability of resource record query load over UDP.
The critical point that Johan makes is that the response size of a DNSKEY is predictable from the parent DS (as this contains the algorithm). A resolver that recognizes such queries for DNSKEY records with a ‘large’ algorithm signature can use a query over a streaming transport — take your pick of TCP, DNS over Transport Layer Security (DoT), DNS over QUIC (DoQ), or DNS over HTTP (DoH) — directly without the need to perform the dummy UDP query and truncated response as a precursor to the query.
The reason that DNSSEC algorithm rollovers are complex is that they involve both the parent and the signing of the entire zone (double signatures due to the ‘algorithm completeness’ requirement of RFC 4035). If we split the KSK/ZSK algorithms, then this entire algorithm rollover problem disappears. A ZSK algorithm rollover becomes literally trivial, as the signer just switches to the new algorithm when generating new keys and the new ZSK will propagate through the DNS. A KSK algorithm rollover requires two signatures, but its impact can be contained, because it only affects the DNSKEY RRset that we already know in advance will be large.
Even if you accept the premises that lead to the view that we should be working on PQ-DNSSEC now, it does not appear to require a gigantic leap into a technically and economically challenging future for the DNS. It appears that we already have working approaches that can be supported on today’s resolvers and network infrastructure. But loudly proclaiming ‘job done’ in the IETF is a complete waste of time! Expect more side-meetings, spin-off research groups, and working groups before we are done with this topic!
Slides: PQ DNSSEC Experiments, Johan Stenstam, PQ-DNSSEC Side Meeting
Optimistic DNS
There are several topics in the DNS where everybody has an opinion, and when opinions are traded, it also seems that everybody is an expert!
One topic is the task of managing a cached copy of DNS data in a resolver. When a resolver is passed DNS data, it generally has an associated TTL that specifies the length of time the resolver can use this local copy before it must refresh it. Let’s say that again, because it’s important — the resolver can retain and reuse this data for the period of time given by the TTL, but should not use it thereafter.
This TTL value allows the source of the DNS data a lever to control the ‘freshness’ of these copies. It also governs the behaviour of the propagation of changes in the DNS. For example, if a change is made at the source, then it can be assumed that the new value will be used everywhere at the expiration of the TTL period after the change.
DNS queries have a close-to-inescapable delay associated with them, and this delay has prompted various proposals related to refreshing cached DNS data and TTLs.
One approach is called prefetch, where a locally cached DNS object is queried shortly before the cached object’s TTL expires. This behaviour does not interrupt the delivery of DNS responses for this object, as the query is a background function, and the cached state is renewed for another TTL interval upon completion of the query. There is a tradeoff in performing a query and refreshing the cache even when no client is asking for this object.
Another approach has been borrowed from multicast DNS (mDNS), where the cached object is retained in the local resolver once the TTL expires. When the resolver receives a query for this object, it will respond with this stale object, and at the same time the resolver will initiate a query to refresh the local copy of the object. This is the background to the optimistic DNS proposal.
One view is that this is a harmless corruption of the intended TTL purpose. The expired cached copy is only used once, and as the cache object is being refreshed at the same time as the expired object is being used in a response, it’s likely that subsequent queries will be answered with refreshed data, and the momentary lapse will pass unnoticed. The optimization is a faster DNS response for those cases where the cached data has expired.
The other side of this debate is the observation that the TTL value has been set by the domain operator, and if they were happy to accept that cached information would be used for a longer period, then they would’ve used a longer TTL!
What is missing from optimistic DNS is any secondary specification of a threshold of useable staleness! The entry being used to respond to a query may be hours or even days older than the TTL would normally dictate. Control is now with the resolver managing the cached copy of the data, not the authoritative source of the data.
There have been some conversations over the use of a second timer, a ‘staleness’ threshold that would govern the period over which opportunistic DNS could use a stale cache entry. The counterargument is that longer TTLs are always an option here!
Opinions on this proposal are numerous. Mine is that optimistic DNS is evil!
Slides: Optimistic DNS, Gautam Akiwate, DNSOP Working Group
Parent versus child
Speaking of topics in the DNS where everybody has an opinion, there is also the topic of parent versus child in delegation information.
When a DNS server returns a referral response, the response lists the nameserver names of the child zone (and glue records as appropriate), and these records are held in the parent zone. However, the parent zone is not authoritative for this data. It’s the child zone that is authoritative for this data, and in the case of DNSSEC, it’s the child zone NS records that are DNSSEC-signed, not the parent zone.
When a resolver receives a referral response, should it use this nameserver data to query the child zone servers for its version of these NS records, and load those records into its local cache for potential reuse? That behaviour is certainly consistent with the architecture of the DNS.
However, does it provide any incremental benefit to the integrity of the DNS resolution process?
If the delegation information at the parent is incorrect, and the referral response misleads the resolver, then there is no assurance that any subsequent query to the child nameserver would provide authentic data. If the parent’s delegation is misleading resolvers, then there is no way that a resolver can establish that this is a misleading response, nor what the genuine response may have been.
Now if you are using DNSSEC validation, and validating the child NS records upon each delegation, then you might be able to detect the incorrect response at the time of delegation, but if the parent is deliberately misrepresenting a delegation, then there is no reason why it would provide the authentic DS record in any case! It can represent the bogus delegation as an unsigned delegation.
It’s challenging to make the case that the additional queries and time taken to retrieve the child-side records of a delegation increase the robustness of DNS resolution. BIND, for example, has dispensed with these revalidation queries, arguing that the additional time and queries spent in revalidation provide no substantive additional protection in any case.
But the DNS is a massive component of the Internet’s infrastructure. Making a case that all resolution functions should include the additional load of completely extraneous queries is, in my opinion, a completely misguided attempt to adhere to architectural correctness. Nobody knows or cares, and the ability to mitigate rogue parent redirection responses is non-existent. This strikes me as an action that lies somewhere between misguided and darkly malign!
Perhaps the issue here is the apparent out-of-band tooling to synchronize child and parent data for a delegation. When the child changes its delegation records, there is no in-band DNS mechanism that would allow the parent zone operator to be aware of the change and pick up the updated delegation information. The process relies on a variety of provision actions that are often highly customized, show various levels of idiosyncratic behaviours, and often lie outside the direct control of the child domain.
However, that need not be the case. RFC 9859 proposes an in-band mechanism that can automate this process of synchronizing the parent with the child’s zone’s published delegation data in standardized ways. If we supported this signalling mechanism, then the result would be an improved synchronization between parent and child delegation records, and the whole issue of revalidation would be largely irrelevant as a means of catching inadvertent operational errors in delegation.
And as for the case of a rogue parent zone operator, the problem is that, in a hierarchical system, all descendant objects are dependent on their parents. It’s the nature of the beast.
Presentation: Delegation Revalidation, Shumon Huque, DNSOP Working Group
Tales of the root
I remember being lectured by a member of the DNS community a couple of years ago that the root zone was nothing special. It was just another DNS zone and should be treated as such.
I beg to differ.
In a hierarchical system, the apex of a hierarchy is incredibly special. Its absence will bring the entire DNS hierarchy to a screaming crash, and if it chooses to misbehave and act incoherently, the system will collapse into chaos. This is true for any hierarchical system as much as it’s true for the DNS.
There’s no doubt that the root zone warrants consideration. Even in a world of caching, the availability of the root zone is critical, and when a recursive resolver is isolated from the root zone, its lights will turn off as its local entries expire! Where a query’s TLD is not found in the local cache, the resolver must start with a query to the root zone, and this represents a potential privacy vulnerability.
What measures can we take to improve the further scalability of the root zone and at the same time improve its privacy properties, resilience, and mitigate some of the side effects of unavailability?
There’s Query Name Minimisation (qmin) to limit the information leakage to root servers by only querying the servers for the top-level domain in the query name. There’s Aggressive NSEC Caching that can load the local cache with ranges of non-existent names. And there’s the use of DNSSEC to validate responses to provide assurance of the authenticity and currency of returned data. All of these techniques can apply to all queries, and in this context the root zone is nothing special.
There is also local root, a process that periodically loads a copy of the complete root zone into the local recursive resolver and uses this local copy to generate responses that would otherwise be passed to the root servers. RFC 7706 describes this approach and RFC 8806 updates it with some further refinement. These days it’s an option that can be enabled in many recursive resolvers. One proposal, where I’m a co-author, proposes that the use of local root be the default behaviour of recursive resolvers on the public Internet, and that an explicit configuration directive is needed to disable it.
There have been some concerns over the capability to distribute the root zone. The counter-observation is that we’ve done an impressive task of distributing web objects at a truly impressive scale. What if we could package the current root zone contents in this way?
We can. Have a look at https://8.8.8.53/root.zone
There are mixed views on this proposal. Some see this as yet another step in the larger process of reducing the visibility of user actions, and making further evolution of the platform and its services harder. Others see this as a necessary response to prior instances of perceived abuse of a more open network, and a way to remove an anachronistic reliance on the questionable altruism of the US-dominated clique of root server operators.
The IETF often has a hard time working through issues where there is a divergence of opinion. The mantra of ‘rough consensus’ has been variously used to push through outcomes despite vocal opposition, and to stall any changes to the status quo. In this case we appear to be stalled.
Slides: RSS Communication / LocalRoot / RootCache, Wes Hardaker, DNSOP Working Group
Automating DNS delegation management
In the structure of the DNS, the delegation of a name is a central concept, and the ongoing operational task is to take the child zone information — the NS records, and the DS record if the zone is DNSSEC-signed. This has been conventionally performed by some form of out-of-band provisioning process. A DNSSEC-signed zone allows the child zone to publish DNSSEC-signed data for the NS, DS, and glue records it would like loaded into the parent zone, allowing the parent to satisfy itself about the authenticity of a child’s request.
However, it’s not so straightforward if the zone is not DNSSEC-signed. It’s possible to use dynamic DNS and SIG(0) for a similar outcome. The proposed process is:
- The child discovers the parent’s
UPDATEreceiver usingDSYNC(RFC 9859). - Child sends the change (NS, DS, glue) as a plain RFC 2136 / RFC 3007
UPDATE,SIG(0)-signed (RFC 2931) over TCP (or preferably DoT). UPDATEreceiver discovers and validates the child’sSIG(0)key, applies policy, and updates the parent.
The essential component here is secure UPDATE in the DNS, as specified 26 years ago in RFC 3007. An UPDATE can specify insertions or deletions of DNS data, along with prerequisites necessary for the updates to occur. All tests and changes for a DNS update request are restricted to a single zone, and are performed at the primary server for the zone. The primary server for a dynamic zone must increment the zone Start of Authority (SOA) serial number when an update occurs or before the next retrieval of the SOA.
It’s an interesting approach to an old problem.
Slides: Automating DNS Delegation Management via DDNS, Johan Stenstam, DNSOP Working Group
DELEG
The split of the ‘core’ DELEG work into the DELEG Working Group and DELEG Extensions (DELEXT) to the DNSOP Working Group is somewhat surprising to me. It appears to underline a view that in the DNS, two Working Groups cannot work on the same technology platform at the same time.
Fair enough, I suppose, but that leads to the obvious question: Why have a separate DELEG Working Group in the first place? If any artefact is totally intrinsic to the DNS, it’s delegation. If we can’t talk about concepts such as server selection, referrals, signing, validation, and the security exposure in two working groups at once, then how can we cleave out the ‘core’ delegation component into a separate working group and a separate conversation from DNSOP?
DELEG is not a minor addition to the DNS. As was pointed out in the DELEG Working Group meeting:
“For [DELEG]] to be actually useful and deployable, we have to change the authoritative servers, signers, validators and resolvers. Basically everything.”
At this point, the case for general industry adoption of DELEG could not be much weaker!
The IETF moves in mysterious ways at times, and sometimes in ways that seem entirely inexplicable and unpredictable.
Recording: DELEG discussion
IETF 126
The IETF does a really good job of collecting the presentation material and the video and audio records of all the Working Group sessions throughout the week. View them online now.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.