DNS and DNSSEC: what signing changes and what it breaks
Somebody ran your domain through a scanner, it came back with “DNSSEC: not signed” or worse “DNSSEC: broken”, and now the question has landed on you. DNSSEC is a set of signatures on your DNS records that lets a resolver prove an answer came from you and was not altered on the way. Unsigned means nobody can check that. Broken means resolvers that do check will refuse to hand out your address at all, so your domain stops existing for everyone behind those resolvers, and nobody at your end sees it happen.
The beliefs that arrive with the ticket
Start with what DNSSEC is for, because the name misleads. It sounds like encryption, a sort of HTTPS for DNS, and it is nothing of the kind. Every DNSSEC query and answer still crosses the wire in plain text, exactly as before. Anyone on the path can still read which names you look up. Privacy for DNS lives in DNS over TLS and DNS over HTTPS, which are different mechanisms with a different job.
Signing your zone gives you one thing: a resolver can reject a forged answer for your name. That is narrower than the “secure” the scanner report implies. A phishing mail claiming to come from your address passes untouched, because stopping that is the job of DMARC and the records underneath it. The certificate on your web server is TLS territory. If the report lumps them together, the report is wrong about the boundaries, and you should say so.
The belief that causes the outages is that it was switched on at the registrar years ago and can be left alone. What you switched on is a chain: a link at your registrar, a link at your DNS host, and signatures that expire on a timer. When any of those changes without the others, the chain breaks. People move DNS providers far more often than they think about DS records, and a move with the old DS left behind is the first cause to check.
Signing, link by link
Your DNS host takes each record set in the zone and produces an RRSIG record alongside it, signed with a private key. It publishes the public half of that key in the zone as a DNSKEY record and hands a digest of it up to the parent zone (the registry for your TLD) as a DS record. The parent signs its own DNSKEY the same way, the root vouches for the parent, and every validating resolver ships with the root key built in. Those links, from your zone up to the root, are the chain.
A DS record at the parent looks like this:
yourdomain.example. 3600 IN DS 2371 13 2 1F987CC6583E92DF0890718C42D45A7C4B6B2F1A3B4C5D6E7F8091A2B3C4D5E6The four fields after DS are the key tag, the algorithm (13 is ECDSA P256 with SHA256, the sensible modern default), the digest type (2 is SHA256) and the digest itself. The key tag and the digest have to match a DNSKEY being served in your zone right now, and after a provider move or a key rollover the DS at the parent often still points at the old key while a different key is answering queries today.
When a validating resolver fetches your A record, it also fetches the RRSIG, checks it against your DNSKEY, checks the DNSKEY against the DS at the parent, and walks up to the root. If every step verifies, it sets the AD flag (authenticated data) and returns the answer. You can watch it do this:
$ dig +dnssec yourdomain.example A
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
yourdomain.example. 300 IN A 203.0.113.10
yourdomain.example. 300 IN RRSIG A 13 2 300 20260920000000 20260906000000 2371 yourdomain.example. jK8...The ad in the flags line is the whole point of the exercise. The two timestamps in the RRSIG are the validity window. Note the second one: signatures expire, and a signer that stops running will let them lapse.
A wrong chain fails closed
If the DS at the parent does not match a live DNSKEY, or the RRSIGs have expired, or the zone claims to be signed and serves no signatures, a validating resolver treats the answer as forged and returns SERVFAIL, with no fallback to treating the zone as unsigned:
$ dig +dnssec yourdomain.example A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51233
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1The user gets no IP address and no error they can act on. Browsers render their generic “this site can’t be reached” page. Mail servers trying to deliver to you log something like this and queue the message for retry:
Host or domain name not found. Name service error for name=yourdomain.example type=MX: Host not found, try againThe failure is total for anyone behind a validating resolver, 1.1.1.1 included. It is also invisible from inside the office if the office resolver does not validate, which is why the classic symptom is “it works for me, customers say the site is down”. Run the query again with +cd (checking disabled) and it answers normally, which confirms the records exist and the chain is the problem:
$ dig +cd yourdomain.example A
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1
yourdomain.example. 300 IN A 203.0.113.10delv from the BIND tools names the fault directly, and its messages are worth recognising on sight:
;; no valid RRSIG resolving 'yourdomain.example/DNSKEY/IN'
;; broken trust chain resolving 'yourdomain.example/A/IN'
;; resolution failed: broken trust chainWork through the causes in this order. You moved DNS hosting and the old DS record is still at the registrar, so the parent vouches for a key the new host never had. The new host signs with its own key and nobody updated the DS. The DNS host stopped resigning, or somebody exported the zone to a plain file and imported it without the signing pipeline, so the RRSIGs aged out.
The last cause is the registrar dropping the DS during a transfer, so the zone is signed but the parent no longer says so; that is the one case that fails open rather than closed. The diagnosis for each is on the broken chain page, with the exact commands.
The census numbers
The failure mode above sounds rare. The census says it is rare and also not zero. Of the 316,600,902 domains where the DNSSEC check ran in the September 2026 census, 21,732,692 (6.9%) carry a signed chain that validates. A further 173,606 (0.05%) are signed and broken: a validating resolver will not hand out their addresses.
The remaining 294,694,604 (93.1%) are unsigned. So when a scanner flags your domain for no DNSSEC, understand that it is flagging you along with most of everything registered. The gap is still yours to close, and the scanner is holding you to a standard most of the web has yet to meet.
Adoption is very uneven by TLD, and the difference comes down to registry policy. Where a registry makes signing the default path and its registrars automate the DS, signed zones become the norm under it; where the registry does nothing, adoption sits near the global figure. The per-TLD breakdown is on the census data page.
Do I need DNSSEC?
It depends on what a forged DNS answer would cost you. The attack DNSSEC prevents is cache poisoning: an attacker gets a resolver to accept a fake A or MX record for your name, and users of that resolver are sent to a server the attacker controls. If you hold customer logins or receive confidential email, a poisoned resolver at an ISP is a real loss. If you run a brochure site, it is a smaller one.
The less obvious reason is that other controls are starting to depend on it. DANE (publishing your TLS certificate fingerprint in DNS) only works on a signed zone, so if you ever want DANE-verified delivery to your mail server, DNSSEC comes first. CAA records, which tell certificate authorities who may issue for your name, are checked whether or not the zone is signed; what signing adds is that nobody can forge an answer saying you have none. And the questionnaires and scanners your customers run increasingly treat “unsigned” as a finding, which is presumably why you are reading this.
Against that, weigh the operational cost. A signed zone has one more way to fail, and when it fails the whole domain goes with it. If your DNS host does the signing and the DS publication for you, the cost is close to nothing. If it means running a signer yourself and hand-carrying DS records to a registrar web form every rollover, be honest about whether anyone will still be doing that in three years. If the answer is no, leave it unsigned, because an abandoned signer eventually takes the domain down with it.
Check your own chain in two minutes
Before you answer anyone, look at what the resolvers see. From any machine with dig:
$ dig +short DS yourdomain.example @1.1.1.1
$ dig +short DNSKEY yourdomain.example @1.1.1.1
$ dig +dnssec +noall +comments yourdomain.example A @1.1.1.1If the first returns nothing, the parent has no DS for you and the zone is unsigned as far as the world is concerned, whatever your DNS host’s control panel says. If it returns a DS but the second returns no DNSKEY, or the key tags do not match, you are in the broken state and need to act today.
If the third shows status: NOERROR with ad in the flags, the chain is valid and the scanner finding is about something else. The free scan below runs the same checks and shows you the chain state next to the rest of your DNS and email posture, so you can answer the whole report at once.
Turning it on without losing the domain
Done in this order, no step leaves resolvers refusing your zone. First, confirm your DNS host supports signing and, ideally, publishes CDS and CDNSKEY records, which let a cooperating registry pick up your DS automatically. Second, enable signing at the DNS host and wait. Check that RRSIGs are being served and that dig +dnssec against the host’s own name servers shows them. Do not touch the registrar yet; a signed zone with no DS at the parent is an unsigned zone to resolvers, which is safe.
Third, once the signatures have been stable for longer than your zone’s longest TTL, publish the DS at the registrar. Copy the DS the host gives you exactly; the digest is hex and a single dropped character produces the SERVFAIL above. Fourth, verify from the outside with the commands in the previous section, and again with delv, before you close the ticket.
Once it is live, never change DNS providers without first removing the DS at the registrar, waiting a TTL, then moving, then publishing the new host’s DS. And put a monitor on dig +dnssec returning ad, because a broken chain raises no alert of its own, and without one the first person to notice will be a customer.
Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.