DNSSEC: Protecting Your Traffic From Forgery

Every name your machine looked up today, it believed. Your bank, your updates, your mail server. An answer came back off the network and nothing anywhere checked whether it came from the organisation that owns the name or from whoever got a packet in first. There is no signature on an ordinary DNS answer, nothing to verify, and nothing that would notice if there were something wrong. That was a reasonable design in 1983 and it stopped being one a long time ago.

DNSSEC is the fix for exactly that, and it is neither new nor expensive. The zone’s owner signs their records. The zone above them publishes a hash of their key and signs that, and so on upwards, until the chain reaches a single root key your resolver was born knowing. Anything that checks the chain can tell a real answer from a forged one. It has been a standard since 2005, the root has been signed since July 2010, and the registries publish the records for nothing.^{1 2}

The top of the tree is finished. I counted the live root zone for this post and 1,351 of 1,438 top level domains are signed, every one of the 1,038 generic ones among them. Then it falls off a cliff. Of the 2,390 gov.uk domains that still resolve, thirty-nine are signed, and nine of those are parish councils. MI6 managed it. The National Cyber Security Centre did not.

This is what a forged answer actually costs and what signing does about it, counted from the live root zone on 27 September 2026 and down through government, the banks, the distributions you install from and the certificate authorities. One command per domain, nobody’s permission needed, and every name listed so you can argue with my choices rather than my arithmetic. Underneath it is the question I actually wanted answering. Forty-two years after Mockapetris wrote DNS down, is the reason almost nobody signs that almost nobody ever understood what DNS was promising?

What DNSSEC Is, And What It Is For

In one sentence: DNSSEC puts a cryptographic signature on DNS answers, so a resolver can prove an answer came from the zone’s owner rather than from whoever managed to reply first.

It is not encryption, it is not a firewall and it is not a filter. It is a signature and a chain of keys reaching back to a single key your resolver already trusts. That is the entire idea.

Now the attack, because the protocol only makes sense once you have seen what it is for.

A resolver asking for a name sends a query and waits. The answer is matched on a handful of fields: the query name, the type, the source and destination addresses and ports, and a 16 bit transaction ID. Anybody who can produce a packet matching those fields, before the real answer arrives, wins. The resolver caches the forgery and hands it to every client that asks, for as long as the attacker said to.

Dan Kaminsky’s 2008 work is the one everybody half remembers.³ The bit that matters is not that cache poisoning existed, because it was known about for years before that. It is that he found a way to retry the guess indefinitely. Ask for a name that does not exist, and each failed attempt costs nothing and lets you try again immediately, so the attacker is no longer racing once against a cached record that lasts a day. The industry response was to add randomness: random source ports on top of the random transaction ID, which took the guess from one in 65,536 to something around one in two billion.

That is a bigger number. It is not a proof.

And the mitigation has been eroding ever since, because every one of those fields is a guess made harder rather than a fact made checkable. Port randomisation gets undone by a NAT that rewrites ports predictably. Fragmentation attacks sidestep the matching entirely. Off-path attacks keep coming back in new forms, and each one gets its own patch.

Signing ends the argument. A signed answer either verifies against a key the resolver can chain to the root, or it does not, and no amount of guessing gets an attacker a valid signature.

What Winning That Race Actually Buys Them

Be concrete about it, because “cache poisoning” sounds abstract and the consequences are not.

The third row turns a DNS problem into a certificate problem. Domain-validated issuance works by asking you to publish a record and then looking it up. If an attacker can control the answer the CA sees during that lookup, the CA issues them real paper for your name, and after that the padlock in the browser is theirs. Everything a user has been trained to check will say the site is fine.

The fourth row is the quiet one. A forged answer does not have to send anybody anywhere. Pointing an update service at a black hole is enough, and nothing in the stack is built to shout about updates that never arrived.

What Signing Does About It

The mechanism is simpler than its reputation.

Every signed zone holds a key pair. The zone owner signs each record set with the private half and publishes an RRSIG alongside it. The public half goes in the zone as a DNSKEY. So far this proves nothing, because an attacker who can forge an A record can forge a DNSKEY to go with it.

What closes it is the DS record, and the DS lives in the parent zone, not yours. It is a hash of your key, published and signed by the zone above you. So uk vouches for your key, the root vouches for uk, and your resolver was born knowing exactly one thing: the root’s key.²

Three record types do the work, and you want to know which is which, because only one of them is somebody else’s job:

You can publish the first two on your own all afternoon and it changes nothing. Until the parent publishes a DS, you are a signed zone that nobody can verify, which is the same thing as an unsigned zone with extra work in it.

$ dig +short @127.0.0.53 uk DS
43876 8 2 A107ED2AC1BD14D924173BC7E827A1...

$ dig +short @127.0.0.53 damiendye.uk DS
2371 13 2 A5B2825C57899A5A15EE9703832C8358E0D19EF29DC72DD83C691ED77C33BD7F

$ dig +short @127.0.0.53 bbc.co.uk DS
                                          (nothing)

That is this site’s own zone in the middle. uk vouches for it, algorithm 13 is ECDSA P-256, and a validating resolver can therefore prove every answer about it back to the root. bbc.co.uk returns nothing, so it cannot.

One command tells you whether a zone is in the chain of trust. If the parent publishes no DS for you, you are not signed, whatever else you have configured, and a validating resolver will treat every answer about your domain as unverifiable.

That one record is the whole test.

What It Does Not Do

Worth saying plainly, because overselling it is half of why people distrust it.

People trip over that last row. DNSSEC proves the answer came from whoever controls the zone. It has no opinion whatsoever on whether they are decent.

It does exactly one thing. It makes forging an answer arithmetically infeasible rather than merely unlikely.

How To Check Any Zone, Including Somebody Else’s

This is the part that makes the rest of the post possible, and it takes one command.

A zone is in the chain of trust if its parent publishes a DS for it. That is the whole test, and you can run it against anybody, without permission, from any machine:

dig +short damiendye.uk DS

Something back means signed. Nothing back means not signed, whatever else the zone has configured.

If you want more than a yes or no, there are three more worth knowing:

Two traps to know before you trust your own results, because both caught me while measuring this post.

dig +short … DS will print a CNAME chain if the name is aliased, and a hostname containing digits looks enough like a DS record to fool a naive script. A real DS is four fields: key tag, algorithm, digest type, hex digest. Match that shape, or you will count unsigned zones as signed.

A DS under an unsigned parent means nothing. The chain has to reach the root. update.microsoft.com has a DS, and microsoft.com does not, so the branch is unverifiable regardless. Always check the whole path, not one level.

Everything counted in the rest of this post was measured this way. No scanner, no third-party dashboard, no vendor’s league table. Ask the parent whether it vouches for the child, and insist the answer parses as a DS.

The Root Zone Is Finished

Here is where the received wisdom is simply out of date. People still talk about DNSSEC as though the infrastructure is the problem.

I fetched the live root zone on 27 September 2026, serial 2026092701, and counted the delegations against the DS records.⁴

Every single generic top level domain is signed. All 1,038 of them, no exceptions, because ICANN’s Registry Agreement requires it of anything delegated under the new gTLD programme. The 87 that are not signed are almost entirely country codes, and the list is mostly small territories and a handful of states:

ae ao aq ba bb bo bs cd cf cg ck cu cv cw do eg fk gb gf gh gm gp gq gt gu
hm im iq jm jo kh km kn kp mh mk mo mp mq mt mv mw mz ne ni np nr om pa pf
pk pn ps qa sd sl sm so st sv sy sz td tg tj tk to va vg vi ye zw

gb is in there, which is a curiosity rather than a problem, since nobody uses it for owt. So are the Vatican, North Korea, Cuba and Syria. So is tk, which was for years the largest source of free domains on the internet and a reliable source of abuse with it.

So the top of the tree is done. The registries did the hard part, the expensive part and the part that needed international coordination, and they finished it. As such, nothing below this point can be blamed on the infrastructure.

And Then It Stops Dead

Below the TLD, the picture inverts completely.

I measured the same way for every set below: ask the parent for a DS, accept only a record that actually parses as one. Everything here was counted on 27 September 2026.

Ninety-four per cent at the top. One and a half per cent at the bottom. The chain of trust is a chain with one end bolted to the wall and the other end lying on the floor.

A note on method, because a number this bad deserves one. The gov.uk row is a census and not a sample: it is every second level domain in the government’s own published register, filtered to the 2,390 that still resolve. The other rows are curated lists of the organisations whose forgery would actually hurt, which is a judgement call, and I have listed every name in them below so you can disagree with my choices rather than with my arithmetic.

The Government Census: 39 Of 2,390

The official list of gov.uk domains that the government publishes runs to 3,004 second level names. Of those, 2,390 still resolve. Thirty-nine are signed.

Before the detail, one thing about that register. The most recent version gov.uk publishes is dated 1 October 2016.⁵ A decade old, for the authoritative list of the domains that the British state answers on. That is its own small finding and I will leave it there.

Now look at which thirty-nine.

Read that first column again. The Secret Intelligence Service has signed its zone. The National Cyber Security Centre has not.

Neither has GCHQ, which is the NCSC’s own parent organisation. Neither has the Cyber Essentials scheme, which exists to certify that other people’s security is adequate. I am not going to pretend that is anything other than remarkable.

And nine of the thirty-nine are parish and town councils. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Places with a clerk, a part time website and a budget that would not cover a day of consultancy in Whitehall. They managed it. HMRC, which holds the tax record of every adult in the country, did not.

Can I ask what in the process allows that. Not who: what. Because the NCSC publishes guidance telling other people to deploy DNSSEC, and the department that writes the guidance has not done the thing the guidance says. Either it is important, in which case the body that says so should have done it years ago, or it is not, in which case the guidance should say that instead.

The excuse on offer will be scale and legacy. It does not survive the first column. somerset.gov.uk is a unitary authority serving 580,000 people and it is signed. birmingham.gov.uk is a unitary authority serving 1.1 million and it is not. Same country, same registry, same registrars, same money available for the same suppliers. One did it.

The Software You Update From

This is the part that should worry you more than the banks, and it is the part almost nobody measures.

Every machine you run fetches code from somewhere on a schedule, and it finds that somewhere by asking DNS.

Ninety-nine distributions and BSDs, ninety-six of them still resolving. Nineteen are signed.

Nineteen in ninety-six. And the names in that unsigned list are not obscure: Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, every Ubuntu flavour, and both of kernel.org and gnu.org.

The security and privacy distributions are the ones I expected to be different, and mostly they are not. Tails and Whonix have signed, which fits. Kali, Parrot, Qubes, Trisquel and PureOS have not, which does not. OpenBSD has built a twenty-five year reputation on getting precisely this class of thing right and has not signed openbsd.org, while FreeBSD, NetBSD, HardenedBSD and MidnightBSD all have.

The package registries are close to a clean sweep of the wrong column: npm, crates.io, RubyGems, Packagist, Docker Hub and Quay are all unsigned. pypi.org is the exception, and credit where it is due, because it is also among the most attacked.

Microsoft, And The Update Channel

Four of twenty-six Microsoft zones are signed, and they are all one corner of the estate:

The Outlook and Office names are signed and nothing else is, which looks like one team’s decision rather than a company’s. Note what is in the right-hand column alongside the update service: github.com and npmjs.com, two of the largest code distribution points on the internet, both Microsoft-owned, both unsigned.

$ dig +short @127.0.0.53 windowsupdate.com DS
                                          (nothing)
$ dig +short @127.0.0.53 microsoft.com DS
                                          (nothing)
$ dig +short @127.0.0.53 com DS
19718 13 2 8ACBB0CD28F41250A80A491389424...

com is signed, so there is nothing technical in the way. Microsoft could publish a DS this afternoon.

The stock answer to why that does not matter is that DNS is only one layer. Update payloads are code signed, the client checks the signature, and the traffic runs over TLS. Break the DNS and you still cannot get code to execute.

That answer depends entirely on the signing being sound. It has not been.

Be precise about that last row, because people overstate it. The stolen key signed identity tokens, not binaries. It belongs in the table for a different reason: the custody of Microsoft’s signing material failed, undetected for two years, through a crash dump and a compromised engineer account.

The rows above it are the code signing failures, and they are worse. Twice in one year, Microsoft’s own hardware certification programme put a Microsoft signature on a working rootkit and shipped it. Not a forged certificate, not a stolen key. The legitimate process, signing malware, exactly as designed.

So the defence that lets you treat DNS as optional has been subverted by forgery, by process abuse and by key theft, over eleven years. An attacker holding a signature the machine will accept is not a thought experiment. To a state-backed actor it is a procurement problem, not a research one.

Give that attacker a forged DNS answer and the picture is complete: signed code they control, delivered from a server the machine believes is Microsoft’s, over a connection nothing in the stack will question. That is Flame, with better key material.

DNSSEC is the only layer in that chain that does not care whose signing key the attacker holds. It does not validate the payload, it validates where the machine was sent, and it fails independently of every certificate and signature in play. Which is precisely what you want from a second layer, and precisely why it should not be the one that is switched off.

And there is a cheaper attack that needs no key at all. Forge the answer so the update service resolves nowhere useful, and the machine simply never patches. No error the user will act on, no alarm, just a fleet quietly falling behind while the dashboard says everything is fine. If I wanted an estate ready to exploit in six months, I would not push anything to it. I would just make sure nothing arrived.

The Banks, In Full

Not a sample this time. Ninety-eight UK banks and building societies, every one of them resolving on the day, from the high street down to societies with one branch and a Victorian name.

Thirteen are signed.

Thirty-eight building societies. Not one of them signed. Those are the institutions holding the mortgage on a great many houses.

Two patterns in that signed column stand out. Lloyds Banking Group has signed three of its brands, lloydsbank.com, halifax.co.uk and bankofscotland.co.uk, and the Co-operative Bank has signed both of its. So the decision is taken once, at organisation level, and then applied. No per-domain hurdle in it.

And Monzo has signed while Starling has not. Two challenger banks founded within a year of each other, on comparable modern infrastructure, with the same regulator and the same registrars available. One did it.

The One Place Where Everybody Does It

Look at the last two names in the signed column: allica.bank and weatherbys.bank.

.bank is a restricted top level domain run by fTLD Registry Services, and its security requirements make DNSSEC mandatory, alongside TLS and email authentication, with annual re-verification of every registrant.⁹

Two is a small number, so take it as a demonstration rather than a statistic. The requirement is still the only thing that changed.

That is the answer to every excuse further down this post, and it arrives before the excuses do. The same banks, the same suppliers, the same budgets and the same skills produce 13% compliance when it is optional and 100% when somebody checks annually. Nothing technical moved. Somebody just asked.

Nobody Is Guarding The Guards

One certificate authority in nine.

These are the organisations whose entire business is proving that something is what it claims to be. They are also the organisations that validate domain control over DNS, by asking you to publish a record and then looking it up. The lookup that decides whether you get a certificate for a domain is, at eight of these nine, a lookup nobody can verify.

No hypothetical, that one. It is the documented shape: forge the validation lookup, get the certificate issued to you, and now you hold valid paper for a name you do not own. DNSSEC is one of the few things that makes that materially harder, and the people it would protect most have not deployed it.

I will tell you this for nowt. If your business model is identity, and you have not signed your own zone, the argument that it is hard is not available to you.

And Who Is Actually Checking?

Signing is only half of it. A signed zone protects nobody unless something on the other end verifies the signature, and this is where the picture gets worse rather than better.

There are two places validation can happen, and they are not equivalent:

Nearly all the validation in the world is the first kind. Google, Cloudflare and Quad9 all validate, and between them cover an enormous number of users. That counts for something. But it means the property most people have is my resolver says this was fine.

What Each Operating System Can Do

Two of those deserve more than a row.

Apple quietly did the work. iOS 16 and macOS Ventura added client-side DNSSEC validation, in Apple’s own words at WWDC 2022: “iOS 16 and macOS Ventura now support client side DNSSEC validation.”¹⁰ It is opt-in rather than automatic, and it is opt-in at the right granularity, so an application that cares can ask for it per session or per request:

let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true

A real validating resolver on a phone, checking signatures on the device, and almost nobody noticed it ship. Before that, mDNSResponder exposed kDNSServiceFlagsValidate for anyone willing to use the C API.

Android does not offer it. The DNS resolver has been an updatable module since Android 10 and it gained DNS over TLS in Android 9, so the platform has not been standing still on DNS. But neither the AOSP resolver documentation nor the public DnsResolver API documents DNSSEC validation, and the reason libraries like MiniDNS exist and advertise bringing “DNSSEC close to your application” is that the platform does not bring it. I could not find a primary source stating flatly that it is impossible, so I will put it no higher than: not offered, and you would be writing it yourself.

And It Gets Discarded Even Where It Works

One more thing, from this machine, which I did not expect to find.

The upstream resolver here validates and says so. systemd-resolved, with DNSSEC=no, throws that away before any application sees it:

# ---- before: stock Fedora, DNSSEC=no ----------------------------------
$ dig @192.0.2.53  damiendye.uk A | grep flags      # the upstream
;; flags: qr rd ra ad

$ dig @127.0.0.53  damiendye.uk A | grep flags      # the local stub
;; flags: qr rd ra

# ---- the fix: two lines in a drop-in ----------------------------------
$ sudo mkdir -p /etc/systemd/resolved.conf.d
$ printf '[Resolve]\nDNSSEC=allow-downgrade\n' \
    | sudo tee /etc/systemd/resolved.conf.d/10-dnssec.conf
$ sudo systemctl restart systemd-resolved

# ---- after: same query, same stub, nothing else changed ---------------
$ resolvectl status | grep -m1 DNSSEC=
                    DNSSEC=allow-downgrade/supported

$ dig @127.0.0.53  damiendye.uk A | grep flags
;; flags: qr rd ra ad

Same name, same answer, same second. Before the drop-in the upstream did the work, set the AD bit, and the local daemon dropped it on the floor, so the default is not simply we do not validate here, it is we do not validate here, and we will not pass on the verdict of anybody who did. After it, the bit is back and this time it is ours rather than somebody else’s claim.

resolvectl puts the verdict in words, and it separates the two that matter:

$ resolvectl query damiendye.uk | tail -2
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no

$ resolvectl query ncsc.gov.uk | tail -2
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no

Note what the second one is not. It is not an error. An unsigned zone comes back unauthenticated rather than bogus, resolution succeeds, and nothing anywhere complains. That is the whole problem with 1.63% restated as a command: switching validation on does not make unsigned zones fail, it makes them visible, and only to whoever goes looking.

The Largest Client OS Fails The Most Basic Check

Now the other end of the scale, and it is not close.

The Windows DNS client is, in Microsoft’s own description, “security-aware” but “non-validating”. It does not perform DNSSEC validation. It cannot be made to. What it does instead is ask its configured DNS server to validate, and then look for the AD bit in the reply.¹¹

Three things about that, and none of them small:

• It never checks a signature. The strongest guarantee available to the largest client operating system in the world is a single bit set by whatever machine answered.
• It does not even do that by default. The client only sets the DO bit and requires AD for namespaces listed in the Name Resolution Policy Table, a Group Policy object somebody has to configure deliberately. With no rule in it, the query carries no DNSSEC expectation at all.
• Microsoft says the bit needs IPsec to mean anything. Their documentation is explicit that because the client is non-validating and leans on the server, “IPsec is used to establish this trust relationship”. An AD bit arriving over an unauthenticated link is a claim from whoever got there first, which is the precise attack this whole technology exists to stop.

So on the desktop with the largest installed base, out of the box: no validation, no AD requirement, and no authenticated channel to the resolver. The most basic check is not merely switched off. It was never implemented.

And the usual defence, that client operating systems simply do not do this sort of thing, died in 2022. Apple shipped device-side validation to every iPhone and Mac in the same year Microsoft did not. The comparison is no longer desktop against server, or mobile against fixed. It is one vendor that built it against another that has not.

That matters more than the same gap on Linux does, because of who is affected. A Linux server is usually run by somebody who could turn validation on this afternoon and knows what a DS record is. The machines that cannot validate at all, at any setting, are the ones sat on desks in the organisations whose zones are unsigned in the tables above. systemd-resolved ships the capability switched off, which is a decision you can reverse in a line.¹² The Fisher-Price OS (Windows) ships without the capability.

The Service That Is Held Together By DNS

Everything so far has been names on the public internet. The same hole exists inside the building, and in there it is load-bearing.

Active Directory has no fixed address for anything. A domain-joined machine does not know where its domain controller lives, so it asks DNS. The locator process queries _ldap._tcp.dc._msdcs.<domain> for the controllers and _kerberos._tcp for the KDC, and whatever comes back is what it goes and authenticates against.¹³

dig +short _ldap._tcp.dc._msdcs.corp.example SRV

Forge that answer and the machine takes its authentication traffic to a host you picked. Be straight about what that is and is not: Kerberos will not hand a ticket to an impostor who does not hold the keys, so this is not a domain takeover on its own. It is a position in the path, which is what the interesting attacks are built out of. Force the fallback to NTLM and relay it. Sit in the middle of traffic that was supposed to go to a controller. Or point the whole estate at nothing and watch logons stop.

Group Policy, logon scripts, mapped drives and every trust downstream of the logon are all found the same way. It is the highest value set of names most organisations own, and it is sat there unsigned.

Microsoft built the server half of the fix, and built it well. An AD-integrated zone can be signed, online signing of dynamic zones landed in Windows Server 2012, and because the zone lives in the directory the private signing keys replicate to the other DNS servers through AD replication itself.¹⁴ The genuinely awkward part of DNSSEC, getting keys to the machines that need them, was solved here fourteen years ago by the thing the zone was already replicating through.

Then it stops in the same two places as everything else:

So the internal zone that decides which machine gets to be your domain controller is, in most estates, every bit as unsigned as the public one. The difference is that no outsider can count it, so there is no table in this post shaming anybody. Go and look at your own before you assume.

The Operating System Should Do This, And It Should Be On

Which brings me to the part of this I want to argue rather than count.

Validating a DNS answer is operating system work. It sits in the same class of job as keeping the clock right, carrying a store of trusted certificates and having a TLS stack, and for the same reasons: every application needs it, almost none of them should be writing it, and the check has to happen once, in a place where it can be done properly. We settled that argument for certificates a long time ago. Nobody ships a mail client with its own private opinion about root CAs.

Three of the four platforms above can already do it. Not one of them does it out of the box:

$ grep DNSSEC= /usr/lib/systemd/resolved.conf   # Fedora 44, systemd 259.9
#DNSSEC=no

That is the compiled-in default, written out commented so an administrator can see what it is. systemd’s own manual takes a different view, recommending allow-downgrade in general and true wherever the upstream can be relied on.¹⁵ The code ships, the root trust anchor ships, and the documentation ships recommending you turn it on. The default still says no.

That column is the whole problem. A requirement is one lever, and the .bank count further up shows what it does. A default is the same lever with nobody having to enforce anything, because it decides the outcome for everybody who never opens the config file, and that is very nearly everybody. Optional got us 1.63% in government and 13% in banking. People do not opt into security they cannot see, and being right about the technology has never once changed that.

The honest objection is that validating by default breaks users when the upstream resolver is broken rather than the zone. That is what allow-downgrade is for, and it is a real compromise rather than a free one, because a downgrade is something an attacker can provoke deliberately. Even so, shipping allow-downgrade instead of a flat no would be an enormous improvement, and it would put the breakage where it belongs, on whoever is still running a resolver that cannot handle DNSSEC in 2026.

Turning Validation On, And Which Bit Is Fedora’s

Nearly all of what follows is systemd’s rather than Fedora’s, and runs the same on Debian, Ubuntu or Arch. Two things here genuinely are the distribution’s:

Upstream picks allow-downgrade in meson_options.txt, which is the compromise setting, not the brave one.¹⁶ Fedora compiles it to no and then ships a second main configuration file, and since only the first file found is used, the one that documents the defaults is no longer the one in force.¹⁵ So do not edit either of them. The vendor copy is the package’s and an update will hand your change straight back; the /etc copy is a file whose other lines are silently absent.

Use a drop-in instead, which is what the block further up does. It overrides whichever main file won, it survives package updates, and it holds only the thing you changed. Check the result with systemd-analyze cat-config systemd/resolved.conf, which prints every file in the order applied and settles what actually won.

Three settings, and the choice between the last two is a real one:

Start on allow-downgrade, because a broken resolver then costs you nothing. Move to yes once resolvectl status has said supported for a fortnight and you know what your upstream actually is. Per-distribution detail for everywhere that is not Fedora is in the resolved post.¹²

So What Is Actually Stopping People

Right. The numbers are the numbers. Why?

Four reasons get given, and they are not all rubbish.

Key management was a genuine obstacle and mostly is not any more. Signing used to mean running your own key ceremonies, remembering to re-sign before signatures expired, and rolling keys by hand on a schedule you had to track yourself. That work is now done by the DNS provider on most managed platforms, and signing is a toggle. It is not nothing, but it is no longer a project.

The failure mode is the honest objection, and it is the only one of the four I have real sympathy for. Get DNSSEC wrong and your domain does not degrade, it disappears. Every validating resolver refuses your records, which is what it is supposed to do, and the people who cannot reach you cannot be told why by you, because telling them requires DNS.

Three things make it worse than an ordinary outage:

• It fails on a clock, not on a change. Signatures carry an expiry. A zone nobody has touched since Tuesday can be gone by Sunday because a re-signing job quietly stopped running.
• It fails for some people and not others. Only validating resolvers reject you. Your own monitoring, if it does not validate, will report the site as perfectly healthy while a growing fraction of the internet cannot reach it.
• It fails at the layer you use to fix things. Remote access, your status page and your own email may all be under the name that just vanished.

That fear is rational, it has taken large operators off the air, and any honest case for DNSSEC has to sit with it rather than wave it away.

But notice the shape of it: it is a fear of an operational discipline you do not currently have, not a fear of the technology.

And notice who pays in each column. An unsigned zone that gets forged costs your customers, silently, and nobody ever files an incident because nobody ever finds out. A signed zone that expires costs you, immediately, in public, with your name on the postmortem. Both are failures. Only one of them turns up in anybody’s objectives.

Certificates had the same problem and solved it twice over: the failure was made visible, and then it was automated. A browser warning made an expired certificate everyone’s problem, monitoring followed, and then Let’s Encrypt made renewal something a cron job did at three in the morning. None of that made certificates easier in principle. It made forgetting them harder.

Provider support is worth ten minutes of checking rather than assuming. Some registrars still make publishing a DS a support ticket. Plenty do not.

And the last one is the real answer, which the .bank registry already proved further up this post. There is no browser padlock for DNSSEC. No customer has ever chosen a bank because its zone was signed, no auditor fails you for it, and no general regulation in the UK requires it. The benefit is entirely invisible when it works, the cost of getting it wrong is an outage with your name on it, and the person carrying that outage is not the person who would get the credit.

Put a requirement and an annual check in front of the same institutions and compliance goes from 13% to every single one. Nothing about the technology changed between those two numbers. Nothing about the budgets, the suppliers or the skills changed either. The only variable was whether anybody was going to look.

Given those incentives the surprising thing is not that 1.63% of government domains are signed. It is that thirty-nine of them are.

Turning It On Without Taking Yourself Off The Air

The whole risk sits in one place, so put the effort there. Signature expiry is the failure that arrives with nobody having touched anything, so alarm on it:

dig +dnssec damiendye.uk SOA | awk '/RRSIG/ {print "sig expires", $9}'

Treat it like a certificate. Watch the date, alarm well before it, and make the renewal automatic so the alarm is a backstop rather than a workflow.

Then turn it on at a quiet time, on something that is not your primary domain, and leave it a fortnight before you do the one that matters. If your DNS is on a managed platform the signing itself is very likely a toggle, and the only genuinely manual step is lodging the DS with your registrar.

Is This The Same Failure As IPv6?

It is the obvious comparison, so I measured both standards in the same populations on the same day. Same organisations, same people, two decisions.

Nineteen times further along in government, on the same domains.

Now sit with which is which. IPv6 touches every router, every host and every application, and wants dual stack running in parallel for years. DNSSEC signing is a toggle and one record pasted at your registrar.

The far harder job is beating the easy one everywhere I looked. Which rules out the comfortable explanation that this is just how infrastructure standards go, slowly and grudgingly. DNSSEC is not moving slowly. It is not moving.

One difference belongs to DNSSEC alone. Deploy IPv6 and you get something back: reachability, no carrier-grade NAT to buy. Sign your zone and you personally get nothing. The protection lands on your users, and only on the ones behind a validating resolver. You take on a permanent outage risk on behalf of people you will never meet, and that is a harder thing to put in front of a board than any technical obstacle in this post.

I have written the IPv6 half of this argument elsewhere and will not repeat it here.¹⁷

Is It That We Still Do Not Understand DNS?

Forty-two years since Mockapetris wrote it down in November 1983.¹⁸ Sixteen since the root was signed.

I think the understanding problem is real, and I think it is more specific than people not knowing how DNS works. Plenty of competent engineers can describe recursion, delegation and caching perfectly well. What is missing is one step further on, and it is the step that matters.

Almost nobody has internalised that DNS is an authorisation system.

It is treated as plumbing. A lookup table. Something that turns names into numbers and belongs to whoever runs the network, filed mentally next to DHCP. And that framing is wrong in a way that quietly decides a great deal, because in practice the DNS answer is what decides which machine your traffic goes to, which server your updates come from, and which host a certificate authority believes is yours. Whoever controls the answer controls all three.

You can see the misunderstanding in the pattern of who has signed. Not budget, and not skill either, and once you line it up it is hard to read as anything other than a pattern of what each of them thinks DNS is:

The people closest to DNS as a thing in itself have all signed. The people who consume it as a utility have not, almost without exception, however well resourced and however security-conscious they believe themselves to be. GCHQ has not signed. Eight of nine certificate authorities have not signed. These are not organisations short of clever people or of threat models.

That is also why the 2008 response to Kaminsky was to make the guess harder rather than to finish deploying the thing that makes guessing irrelevant. Making the guess harder is a plumbing fix, and plumbing is how the industry had DNS filed.

A generation learned DNS as a directory, and never revised the entry when it quietly became the thing that decides who you are talking to.

We Built It, And Then We Left It

The registries, the operators and the standards people did the hard part. They wrote it, argued it through the IETF for a decade, signed the root in a ceremony with witnesses, and got 100% of generic top level domains signed. That is a genuine piece of collective engineering and it is finished.

And then the rest of us did not do our bit, because our bit is boring, invisible, carries all the personal downside and none of the credit, and nobody is checking.

That is the shape of every standard nobody enforces: the cost is carried alone, and the benefit only shows up once enough others have carried it too. So the registries carried it, and the people who publish the guidance about carrying it did not.

Except the job here was smaller than almost any of them. The chain was already built, and paid for, by somebody else. All that was left was one record.

And If This Is The Bit We Can See

One last thought, and I want to be clear it is an inference rather than a measurement, because everything else in this post is counted and this is not.

DNSSEC is about the easiest security control there is to assess. It costs nothing, the work is an afternoon, the standard has been finished for twenty years, and anybody can check it from the outside in one command without asking permission. No audit, no questionnaire, no NDA. One dig.

So what does 1.6% tell you about the controls you cannot see from out here?

Every row below the first is harder than signing a zone, costs real money, needs somebody to own it, and shares the exact property that sank DNSSEC: invisible when it works, and nobody outside checking. The only thing separating the top row from the rest is that you can check it, for free, about anybody, right now.

If an organisation has not done the free thing that takes an afternoon and can be verified by a stranger in one command, I am not inclined to assume it has done the expensive things that take a programme and can only be verified by someone they let in.

Now, the obvious move is to test that against the breach record, and I tried. Of 23 UK organisations with documented major incidents, 22 are unsigned.

That number proves nothing and I am not going to pretend otherwise. At a base rate of 1.6%, one signed organisation in a list of 23 is precisely what chance predicts. Worse, the signed set is nine parish councils and three national parks while the unsigned set is every large department and every major city, so size drives both who gets attacked and who ends up in the news. Any comparison of breach rates between the two groups would be measuring how big an organisation is, not whether it signed.

So no, I cannot show you that signed organisations get breached less. Nobody can, not with data anybody can get, and anyone telling you different is kidding.

The Organisations That Got Hit Wrote Down What Failed

You do not need my inference, because they published it themselves, and what failed is the list above.

The British Library is the best of them, because they wrote it down voluntarily and in detail after their 2023 ransomware attack. Their own review names the causes: entry most likely through a third-party account on a Terminal Services server with no multi-factor authentication, then legacy infrastructure and limited network segmentation letting the attackers move across the estate, with the growing complexity of third-party access having been flagged as a risk internally in 2022 and still there a year later.¹⁹ The ICO reached the same conclusions.²⁰

Three rows of the table above, then, confirmed from the inside by the organisation itself rather than inferred by me from out here.

And before anybody uses that as a stick, the British Library deserves the opposite, and I will be emphatic about why.

They were open. Almost nobody else is. There was no obligation on them to write a word of it down. The standard playbook after an incident is to say as little as the law allows, put it through a communications team, decline to confirm anything specific, and wait for the news cycle to move on. That is what most of the organisations in the unsigned columns above have done when it was their turn, and it is why writing this section at all depends on one institution’s decision to behave differently.

Instead they published an eighteen page review naming their own failures, in public, so that other institutions could learn from them. That is the behaviour you would want from every organisation in this post and get from almost none of them. The reason I can show you what actually fails inside a breached organisation is that the British Library chose to tell you.

And there is a second reason the rest stay quiet, which is worse than a communications strategy. Some of them are not there any more.

KNP Logistics had been moving freight as Knights of Old since 1865. In June 2023 the Akira group got in, encrypted the company and asked for about five million pounds. By September the group was insolvent and 730 people were out of work.²¹ A hundred and fifty-eight years, gone in fourteen weeks, and nobody there is writing up any lessons for you.

So when the unsigned columns above look quiet, that quiet is made of three different things: organisations that have not been hit yet, organisations that were hit and said as little as the law allows, and organisations that were hit and are gone. Only the first group has time left to act.

Which makes the next bit the honest test of my own argument rather than a cheap shot. I checked their zone:

$ dig +short bl.uk DS
                                          (nothing)
$ dig +short bl.uk DNSKEY
                                          (nothing)

bl.uk is unsigned. So is britishlibrary.co.uk. Two years after a ransomware attack that shut the institution down for months, after a public review, after an ICO finding, and after the most thorough round of security attention any organisation ever gets, the free control that takes an afternoon and that a stranger can verify in one command is still not done.

I do not read that as negligence, and I do not think it makes them worse than the unsigned organisations that have published nothing. I read it as the strongest evidence in this post for what the whole thing has been about. If DNSSEC does not get done here, at an organisation that has been through the fire, written the lessons up and had the regulator go over it, then it is not getting skipped because people are careless. It gets skipped because nothing and nobody ever puts it on the list.

That is the honest version of the argument. Not unsigned zones cause breaches, which is unprovable and probably false. Rather: the controls nobody outside can see are, on the published evidence of the organisations who have been through it, just as neglected as the one control everybody outside can see. DNSSEC is not the cause. It is the sample you are allowed to take.

Which is why the measurement is worth taking at all. Not because an unsigned zone is the end of the world on its own, but because it is one of the very few security properties an outsider can check honestly, for free, about anybody, without being let in. Treat it as a smoke alarm rather than a verdict, and then go and ask the harder questions of whoever sets it off.

The Only Part You Control

Which leaves the only part any of us actually controls. Your own zone. Not the NCSC’s, not Microsoft’s, not your bank’s.

Go and ask your parent whether it vouches for you:

dig +short yourdomain.uk DS

If that comes back empty, you are not signed, and on most managed DNS in 2026 the fix is a toggle and a DS record at your registrar. Turn it on, then watch the expiry the way you already watch your certificates, because that is the discipline the whole thing actually needs.

That is the whole job. One record, and a date in your monitoring.

So please, do at least this one. Not because a regulator is coming, because for most of you one is not, and not because anybody will thank you, because they will not. Do it because nobody is coming, and a standard you keep when nobody is checking is the only kind that was ever worth anything.

Thirty-nine parish clerks and a spook managed it. Frame thissen and get it done.