It’s Always DNS(SEC)!

Why is it always DNS?

This fedi post by Mark Reid is not what triggers this article, exactly, but it’s not such a bad start:

OH: “What is it about DNS that people find so difficult? It’s just cache invalidation and naming things.”

The joke being, of course, that it’s a riff on the following:

There are only two hard problems in computer science:

0. Cache coherency
1. Naming things
2. Off-by-one errors.

DELEG WG

OK, that’s enough jokes. Let’s turn to something more serious: the DNS Delegation Working Group (DELEG WG) is working on changes to how delegation works in DNS. For the most part, I welcome this.

But first, some context.

The Current Situation

I don’t want this to be a deeply technical article, so I’ll skim over a lot of the finer points. Readability beats attention to detail in this.

Delegation

DNS is hierarchically delegated. That means that ICANN oversees the processes by which organizations are selected to manage top-level domains{^} That’s the right-most part in a DNS name. There are country-assigned TLDs (ccTLD) and generic TLDs (gTLD).

The former are things like .de or .io. Yes, that last one is a ccTLD for the British Indian Ocean Territory, and has nothing to do with I/O. Although it made for a fun name for a while.

The latter are things like .com or .net or .social. The first two are considered older gTLDs, while the latter is considered newer. Every once in a while, ICANN opens the door for more gTLDs to be registered.

(TLD).

Next up are the names you’d register, such as finkhaeuser.de. I had to register this (directly or indirectly) with the German Network Information Center DENIC, which is responsible for managing the domains underneath the .de ccTLD.

Anything following this is up to me.

At any rate, this organizational delegation is also mirrored in the DNS protocol with a protocol delegation. A bunch of root servers are co-operatively operated around the world, which do nothing but delegate TLDs to the name servers responsible for managing them.

In the case of finkhaeuser.de, the root servers would point to name servers at DENIC. Those name servers then point at name servers I operate, which are responsible for the finkhaeuser.de domain (technically: zone).

Resource Records

DNS is a very simple protocol in principle: you send a query to a name server, specifying a DNS name and a type of Resource Record (RR) you’re interested in. The server either sends those records, or tells you it doesn’t have them.

In the case of delegation, the main record we’re talking about here is the so-called NS record, which unsurprisingly stands for name server. It contains the IP address of a name server responsible for a name.

So if I ask the DENIC name servers for the NS records for finkhaeuser.de, it may respond like this:

$ dig -t NS @a.nic.de finkhaeuser.de

; <<>> DiG 9.18.39-0ubuntu0.24.04.3-Ubuntu <<>> -t NS @a.nic.de finkhaeuser.de
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20114
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;finkhaeuser.de.            IN  NS

;; AUTHORITY SECTION:
finkhaeuser.de.     86400   IN  NS  dns1.ns.unwesen.net.
finkhaeuser.de.     86400   IN  NS  dns2.ns.unwesen.net.
finkhaeuser.de.     86400   IN  NS  dns5.ns.unwesen.net.
finkhaeuser.de.     86400   IN  NS  dns6.ns.unwesen.net.

;; Query time: 14 msec
;; SERVER: 2001:678:2::53#53(a.nic.de) (UDP)
;; WHEN: Mon Apr 13 09:09:00 CEST 2026
;; MSG SIZE  rcvd: 133

You can see in the “QUESTION SECTION” that I asked for the NS record, and the “AUTHORITY SECTION” provides authoritative answers.

Non-Authoritative

The server responds “authoritatively” above, because it has authority over the name. A cache in the middle would respond non-authoritatively, e.g. like this:

...
;; ANSWER SECTION:
finkhaeuser.de.     39312   IN  NS  dns5.ns.unwesen.net.
finkhaeuser.de.     39312   IN  NS  dns2.ns.unwesen.net.
finkhaeuser.de.     39312   IN  NS  dns1.ns.unwesen.net.
finkhaeuser.de.     39312   IN  NS  dns6.ns.unwesen.net.
...

Caches abound in DNS, everything we do on the Internet would put load on the root servers. Typically, they’re part of resolvers, which perform the hierarchical lookup for us, and cache all the answers they receive.

For how long? Each record is given a time-to-live (TTL). When that expires, the resolver must start (parts of) the recursive query again.

And if you didn’t before, now you know why cache invalidation is a core problem with the domain name system alluded to above.

DNSSEC

This whole thing is nice, but how do we know that the resolvers don’t tamper with records and lead us somewhere else entirely?

Enter DNSSEC.

The security extension to DNS works via fairly standard cryptographic signatures.

Along with the root servers, a set of public keys is known to sign TLD records the root servers provide. Then each name server can publish their own public keys for the part(s) they manage.

For each record, there then exists an additional record that provides a signature with the responsible key over the record. Knowing the public key, you can verify the signature, and know the record hasn’t been tampered with.

So far, so good.

Chain of Trust

What’s missing in the above picture is the chain of trust. In principle, the idea is this:

The private key above the double line always remains private at that stage. The public key parts get published, along with the records and signatures for the records.

A resolver can then check the entire chain of trust from the trust root to the record they’re interested in, and ensure that the record they get is correct.

DS and DNSKEY Records

In the figure above, I used a generic “delegation” term rather than referring to the NS records you might expect. That is because delegation with DNSSEC is a tad more complicated. We haven’t published any public keys yet, have we?

Over the years, there have been many proposed mechanisms for distributing them, but they all try to use DNS. If we have a hierarchically delegated key/value store, we’d be silly if we invented yet another, right?

The way things are currently used is the following:

• Reality is a bit messier, because we use Key Signing Keys (KSK) in this scheme, but we actually sign the zone entries with a Zone Signing Key (ZSK).

  For our discussion, this is an operational security improvement, and doesn’t change anything else.

  Every of the above parties publishes their own public keys in their own zone via a DNSKEY record. In this way, they are responsible for disclosing the key they want to disclose.
• The parent zone must contain a DS record, which contains the child zone name and a hash of the child zone DNSKEY items. This is then signed by the parent zone public key.

In other words, we establish the chain of trust via two split records: one record publishes the key used to verify the next hop items. But the other record, DS, links the items in the trust chain together.

As it turns out, NS records are – for historical reasons – not signed, so present a weakness in the delegation chain.

The Problem

Is there one problem? No! A village populated by inflexible stakeholders does not stop introducing new issues…

There are, essentially, two classes of issues with the above.

1. The first is the weakness I alluded to above. Because NS records are not signed, they can still be manipulated by a Man-in-the-Middle. The new destination would have to publish a valid DNSKEY matching the DS record of the parent, though, and sign its zone with that key.

   That means the owner of the zone’s private key would have to collaborate with such an attacker, or they key must have been stolen. The latter seems more likely, and is indeed a risk.

   On the other hand: any time a key gets stolen, cryptographic guarantees go out the window, so it’s debatable how much of an issue this is in reality.

2. Way, way more importantly, the picture above does not include all the stakeholders possible.

Stakeholders

There is a whole slew of jargon I will mostly avoid here for the sake of your sanityTry remembering what registrar, registrant and registry are, and then you haven’t touched on registry service providers yet. That’s a whole other set of terms that overlap with the first…

.

The simple summary is this: I may legally own a zone name, but that does not mean I operate any of the servers associated with it.

Similarly, I may not be technically savvy enough to perform cryptographic signatures for zone entries.

Suffice to say that it’s important to differentiate between legal stakeholders and technical stakeholders in the above figure.

Multi-Stakeholder Delegation

So now we can paint a better picture of how messy this whole thing is.

Our cast consists of:

Parent Owner:

The (legal) parent zone owner; who the parent zone name was registered to.

Parent Operator:

The name server operator of the parent zone.

Parent Signer:

The entity managing the parent zone’s keys and signing zone entries.

Child Owner:

Same as Parent Owner, but for the child zone.

Child Operator:

Same as Parent Operator, but for the child zone.

Child Signer:

Same as Parent Signer, but for the child zone.

Below is a picture of how to coordinate a new key for the child zone.

A few things are of note here:

1. Legally speaking, the parent and child owners must coordinate things.
2. Practically speaking, the parent and child owners do not do anything technical here.
3. There is no communication channel that would tell the child signer when to stop waiting and to initiate “Phase B”.
4. This does not include revocation of old keys, which would involve some of the same steps performed afterwards.

When people claim that DNSSEC is really difficult, I can promise you, it is not the operation of software that signs a zone with a key that they mean. For the most part, it is this.

More Problems

The above ignores already that NS records are not signed. It’d be nice if we could plug that hole as well.

But beyond that, the stability of DNS relies heavily on redundancy. In the case of DNSSEC, there is a long-standing wish for easier multi-signer approaches, in which several parties can sign a zone, and a valid signature from any of those signers is accepted.

Ignoring for the moment that it makes validation harder when the two signers provide conflicting information – imagine blowing this process up to include two signers on the parent, and two on the child side.

The potential for fatal results grows exponentially.

The Solution(s)

For the most part, the above is a process problem. The process here involves parties in an exchange of pieces of information that have zero expertise in handling this information. Additionally, the information is used by systems that are oftentimes entirely automated – except perhaps for where they interface with this process.

There are two different avenues for solving this kind of problem, and ideally they would work hand in hand:

1. On the one hand, at the process level, there should be a means for the owners of zones to indicate to each other what their respective operators and signers are, and allow them to perform the information exchange between them without placing themselves in the middle.

   Not only does this remove two steps from the process that are particularly error-prone. It would also establish the context in which the actual information exchange might be automated.

2. The other part is then that automation of the information exchange.

   Solving that might even make multi-signer approaches operationally feasible.

Enter the Dragon DELEG WG

The DELEG WG exists to bring the above solutions to life.

Well.

That’s not entirely true.

The coordination and management of stakeholders is an issue typically associated with registration of zone entries, because it involves the legal stakeholders.

For that reason, the first avenue above? It isn’t getting addressed.

Be that as it may; the result is that the DELEG WG is attempting to solve a process issue by technical means. That is understandably so, because one can only move things that one can apply a lever to.

I also need to stress that this makes no goddamn sense in this case.

But in the absence of a process level solution, it nonetheless remains the only thing to do.

DELEG Records

Let’s look at the proposal, the soon-to-be DELEG records:

They’re based off SRV records, and

• essentially provide a way for associating multiple key/value pairs with a single zone entry in a single record, and
• are signed with DNSSEC.

The latter thing solves the lack of signature. The ability to include multiple key/value pairs means that it’s possible to make NS delegation richer, by e.g. including glue information. In this way, a name server can be named as in my example above, but additionally, IPv6 and (if you must) IPv4 addresses can be included.

This would provide an additional layer of security and a speed-up, so I’m all in favour of that.

It doesn’t solve the DNSSEC process problem above.

DNSSEC in DELEG

There have been attempts to include solutions to the DNSSEC problem in DELEG, and they fall into two camps, by and large:

1. Add the equivalent of the DS record straight to DELEG.
2. Add a pointer to a key to the DELEG record in the form of a domain name. The pointer essentially indicates “look here for DNSKEY for the domain”.

There are operational and security improvements to the first approach. Essentially, figure 1 above shows two delegation chains: a name delegation chain, and a trust delegation chain.

The issue with unsigned NS records is that the trust delegation chain is broken here. It essentially keeps the name delegation and trust delegation separate, which could lead to divergence between the two.

Even with a signed DELEG record, the two delegation chains remain separate, but they’d intermingle. A set of DELEG+DS records, signed by the same key, creates an indirect link.

But of course, extending the DELEG to include the DS-type data would make this more explicit and actually simpler in the end.

The downside – and if you paid attention, this will jump at you – is that it does nothing for the process challenges.

The second approach with the pointer is a means for side-stepping the process challenges. By allowing for such a pointer, it is now possible for the parent zone to be less involved in the signing process.

The owner of the child zone merely needs to convey where they’re delegating signing to with a name. The parent zone includes this in the DELEG record, signs it, and it’s become part of the overall delegation.

Proponents of this laud it as a practical solution to the operational challenges with DNSSEC.

Cryptographic Analysis

This section’s title is rather grandiose. I do not intend to go into an actual, deep analysis of the proposal on cryptographic grounds. But that is also not necessary. Also, since I go to this effort at all, it is clear that this section is not about DELEG as such, but exclusively about DELEG as a DNSSEC delegation method.

The first proposal? I already stated everything there is to say about it: it plugs some holes, is simple, and also doesn’t change anything about the cryptographic chain of trust, so isn’t worth analysing deeply. But it doesn’t address the process issue, so it’s not popular.

The second approach, well. That’s more complicated.

Discussions around it all stress in some way the thing that has remained hidden, namely that the name delegation chain and the trust delegation chain are two distinct beasts.

Furthermore, the specific proposals being discussed actually split the latter in two as well.

Split Trust Chain

Even though the figure is somewhat complex, you can see the split relatively well.

1. The TLD owner (of .foo) generates name delegation and trust delegation information; the latter is just a DNS name pointing at the signer zone.
2. This information is provided once (or rarely) to the parent zone; it is signed and included in the parent zone (publication of the parent zone is not in the diagram).
3. The delegation information is also included in the unsigned .foo zone. This is sent to the signer, signed there, and returned.
4. The resulting signed zone is served by the .foo name server indicated in the delegation from the first step above.

Verifiable signatures exist everywhere along the way. A signature verifies that the .foo name server is authoritative for everything .foo. That the contents are generated via a process that involves the signer is indicated by the trust delegation pointer.

The signer signs the zone, and provides a full chain of trust back to the trust root.

Resolution & Validation Complexity

There’s one thing I dislike somewhat about the proposal, and that is that resolution and validation is made more complex.

In order to understand why I dislike it, consider that resolver operations are, to date, an unspecified black box.

Yes, you read that right.

There is an expired Internet-Draft from 2024 that documents the process by which a number of resolvers choose servers, and details potential attacks on those algorithms. But this has not resulted in a standard being proposed or implemented to the best of my understanding.

Introducing more complexity into this kind of situation seems to be a recipe for even more issues down the road.

One very specific issue I raised on the DELEG mailing list has been partially addressed, at least in the sense that a solution is possible: as described, it is possible for this split in the delegation chain to occur multiple times. In a properly terrifying setup, it could even lead to looping delegations.

One solution to that issue is to simply disallow multiple splits; consider those malformed. But if and when it comes to standardizing an approach, I’m pretty sure that this is going to be strongly debated again.

Meaning of Signatures

The more complex issue, not because it is technically difficult, but because it is abstract, is that the meaning of signatures changes with the split trust chain.

Outside of cryptography, we have a fairly intuitive understanding of signatures: if you sign a piece of paper, you at minimum acknowledge the information on it. The strongest statement is that you endorse the information.

In cryptography, this is a so-called attestation. And that begs the following question: what do cryptographic signatures in DNSSEC attest to?

The answer to that is nowhere to be found. That is, unless we do some very light archaeology.

When we speak about DNSSEC nowadays, we typically speak about RFC 4034 and it’s companion documents, or later refinements of those. These assume a number of things about the purpose of DNSSEC, however, and fail to explicitly state them.

By contrast the older and obsoleted RFC 2535 is explicit about what “services” DNSSEC aims to provide. Section 2 lists:

• key distribution
• transaction and request authentication
• data origin authentication

We can skip all but the last one, and take an excerpt from that section:

Authentication is provided by associating with resource record sets in the DNS cryptographically generated digital signatures. (…) The data origin authentication key(s) are associated with the zone and not with the servers that store copies of the data. That means compromise of a secondary server or, if the key(s) are kept off line, even the primary server for a zone, will not necessarily affect the degree of assurance that a resolver has that it can determine whether data is genuine.

The meaning here is clear if only by way of this roundabout explanation: the goal is to authenticate data independent of the source of that data.

Which means that the only entity that is capable of providing attestations on the data is the entity responsible for managing it. And that means zone owners.

The trust chain split proposed as a potential later extensions to DELEG breaks that promise, because it is no longer the zone owner that attests to anything.

• The trust root merely attests to a name server and a signer who are independently responsible for serving and signing zone data.
• The signer attests that it has provided valid signatures over the data it received.
• The name server operator attests to nothing.
• The zone owner attests to nothing.

Note that “attests to nothing” above is imprecise. The more precise wording is: there is no publicly available or verifiable information for resolvers to examine.

Risk

Of course it is operationally possible for the zone owner to ensure that the signed zone it receives from the signer is consistent with the unsigned zone it sends to the signer, and not deliver it otherwise. In that case, this signature-by-proxy scheme is just as good as if the owner attested to the data itself.

But how likely is that?

Recall that the issue is a process issue that is circumvented by technical means. The goal is to take the owner out of much of the technical choices, on the argument that this is not their expertise, and so their involvement only serves to complicate matters.

That means that the party that has been identified as the main problem in the existing process is now obligated to ensure that the other parties do something correctly that this first party is least capable of understanding.

I, for one, fail to see how this is going to improve matters.

Implied and Misapplied Cryptography

All cryptographic signatures work in more or less the same way.

Digital signatures attest to something about a subject. Most of the time, this subject is well defined. In this case, the subject is either a cryptographic key, or a DNS name.

What they attest to is often only not specified, but merely implied.

In DNSSEC, this part has been lost to the mists of time in most discourse. But the original idea was that it would authenticate data[^data-authentication], which in more explicit terms means that the author of the data proves that the data is what they authored.

Data Authentication

Data authentication is essentially the “default attestation”, i.e. what a signature attests to when nothing else is explicitly specified. It is the same in e.g. email signatures, etc.

A more explicit attestation, such as exists in web tokens, is perhaps more desirable overall.

Data authentication actually provides several guarantees. In the context of our discussion here, the two vital ones are:

1. The data is exactly what its author intended.
2. No man-in-the-middle managed to modify the data.

If this seems like duplication of the same guarantee, then you’re not entirely wrong. In fact, the second guarantee is included in the first.

But mere man-in-the-middle protection does not necessarily provide the first guarantee. Consider how, when we exchange messages over some web service via a TLS-encrypted connection, the TLS transport encryption protects us from man-in-the-middle attacks.

This is because from a TLS point of view, the client-to-server communication is the only one that matters.

But the actual message exchange was end-to-end. The man-in-the-middle protection is lost at the server. Both parties must trust the server operator to act honestly on their behalf. Since this is not always guaranteed, end-to-end encryption is a vastly more desirable goal.

The first data authentication guarantee is to authenticity what end-to-end encryption is to confidentiality.

Key Authentication

When attestations without explicit attestation topic are issued for cryptographic keys, we’re building a trust chain – the same kind of trust chain as we saw earlier.

It’s important to understand that there is a hard requirement for this kind of trust chain. And that is that the subject (the second key) is either directly used as input of the signature. Alternatively, something is signed that is unbreakably linked to the key.

A common example of the latter is a cryptographically secure hash of the key. The properties of the hash function imply the “unbreakability”. This approach makes sense when a full key is sufficiently larger than the hash that space savings are desirable.

Pointers

I previously described the DELEG proposal as a “pointer”. What I mean by that is that instead of having something unbreakably linked to a key as the subject of an attestation, the link is indirect and breakable.

In this case, the subject is another DNS name, which may or may not resolve to the key that the attestation signer had in mind.

Pointers are always breaks in a trust chain.

Split Trust Chain

Recall that we are dealing with a split trust chain. The split in this case is this:

• We have an unbreakably linked chain from the trust root to the signed zone entries via the signer of the zone data.
• We also have a broken chain from the trust root to the signer, because it is via a pointer from the zone owner to the signer.

The upshot is that while the result can still protect from man-in-the-middle attacks in the same way that TLS can, it similarly does nothing for providing the first guarantee, that the data is as the author intended.

Conclusion

This was triggered by Roy Arends’ “Rethinking Delegation in the Domain Name System” which correctly highlights the importance of the overall DELEG work. Please do not be confused and think I have issues with DELEG here. DELEG on its own is a sensible evolution.

The problem is really two-fold:

First, the meaning of signatures in DNSSEC is changing, from providing data authentication to providing mere man-in-the-middle attack protection.

The second problem is – judging by discussions I’ve had on the DELEG list – that this distinction is not getting visibility.

I can only speculate as to why that’s the case.

Most of the time, this kind of thing occurs when implied assumptions are not made explicit, and discussion partners talk past each other without intending to.

I strongly suspect that’s the case here.

If I were to guess, it may be that one or both of the following are true:

1. The proponents of the “pointer-style” DNSSEC extensions to DELEG are assuming that the purpose of DNSSEC is man-in-the-middle protection.
2. There is insufficient understanding of the distinction between this and data authenticity in the DNS community.

Part of the blame for this, in my opinion, would likely lie in the fact that for the past decades, the guarantees that DNSSEC used to promise have not been kept up to date.

Are DNSSEC goals the same as in 1999? If they have changed – why is that? Where are the reasons documented?

The upshot is that I look at this development with some worry.

Haiku

Anything on DNS would be incomplete without the Haiku.

It’s not DNS

There’s no way it’s DNS

It was DNS

I hope that’s not going to be the end of this particular discussion.