Skip to content
DomainVigil
Sign up

Reference guide

What is DNSSEC?

DNSSEC signs DNS answers so a resolver can prove nothing tampered with them. It is real protection, and the only one whose failure makes the domain disappear instead of degrading it.

7 min readUpdated September 12, 2026

In short

DNSSEC is a DNS extension that signs every answer with a cryptographic key. A validating resolver can then prove the answer really came from the legitimate zone and was not altered in transit. Trust runs down from the root of the internet to your domain, link by link; break one link and the domain goes unreachable for everyone who validates.

What DNSSEC is for

Nobody signs an ordinary DNS answer. Any box along the path can forge one and pass it off as genuine: the browser then heads for a machine that is not yours, with your domain name still in the address bar. DNSSEC closes that door by attaching a verifiable signature to every answer.

What sets DNSSEC apart, and why it is worth watching on its own, is how it fails. When a certificate expires, the visitor gets a warning and can click through. When a DNSSEC signature expires, there is no warning: the resolver simply refuses to answer, and the domain stops existing — no site, no mail, nothing.

The failure is also partial, which makes it confusing: only validating resolvers refuse. A visitor on a network that validates sees nothing at all, while you, on another network, see the site perfectly. That is the outage that costs half a day before anyone thinks of DNSSEC.

The chain of trust, from the root to your domain

DNSSEC does not work domain by domain. It works as a chain: each level vouches for the next, and the whole thing starts from one key every resolver in the world already knows.

  1. 1

    The root signs what it publishes

    The root key is the trust anchor: it ships with the resolver software instead of being learned from the network. It is the one starting point nobody verifies, because it is known in advance.

  2. 2

    The root vouches for the extension

    For every extension, the root zone holds a digest of that extension's key. A resolver that has validated the root can therefore validate the extension's key.

    root → DS for .com → key for .com

  3. 3

    The extension vouches for your domain

    Same mechanism one level down: the extension publishes the digest of your key. That is the link you put in place yourself, by handing the digest to your registrar.

    .com → DS for example.com → key for example.com

  4. 4

    Your key signs your records

    Every record set in the zone — addresses, mail servers, TXT records — carries its own signature, with a start date and an end date.

  5. 5

    The resolver walks the chain

    It starts from the anchor it already trusts and works down to the answer you asked for. If every link holds, the answer is secure. If one is missing or does not match, the answer is bogus and never gets served.

The five DNSSEC records

Signing a zone adds records you see nowhere else. Only one of them lives outside your zone, and that one is behind most outages.

RecordWhere it livesWhat it carries
DNSKEYIn your zoneThe domain's public keys. A zone signing key for day-to-day work, a key signing key for the link with the parent.
RRSIGIn your zoneThe signature over a record set, with a start date and, above all, an end date. That is the date that expires.
DSIn the extension's zoneThe digest of your key, published by the registry at your registrar's request. The only link you do not control directly.
NSEC / NSEC3In your zoneThe signed proof that a name does not exist. Without it, a negative answer could be fabricated outright.
CDS / CDNSKEYIn your zoneWhat your zone asks the parent to publish. Lets a DNS operator roll keys without manual work at the registrar.

The four validation states

A validating resolver does not answer yes or no: it answers with one of these four states. Telling them apart saves you hunting for the fault in the wrong place.

StateWhat the resolver foundWhat the visitor sees
SecureThe chain is complete and every signature is valid.The site answers normally, with proof that the answer is authentic.
InsecureThe parent publishes no digest: the domain is simply not signed.The site answers normally. This is the state of most domains.
BogusA signature is missing, has expired, or does not match the announced key.Nothing. The resolver refuses to serve the answer: the domain looks as if it no longer exists.
IndeterminateNo trust anchor applies to this branch of DNS.The site answers, treated as an unsigned domain.

Only the bogus state takes a domain down, and only for resolvers that validate. Hence the very common report that the site works fine from here.

Check your own domain, right now

Enter a domain name: the report reads its expiry, its certificate, its mail authentication and its DNS records in one pass.

No sign-up, no email required. You can paste a full address — we'll pull the domain out of it.

How DNSSEC breaks in practice

  • The domain vanishes after a change of DNS host

    What causes it: The zone was moved without removing the digest published at the registrar. The new host signs with different keys, or does not sign at all: the digest no longer matches anything.

    What fixes it: Remove the digest at the registrar before migrating, wait for caches to expire, move the zone, then publish a fresh digest once the new signature is in place.

  • The signatures have expired

    What causes it: Automatic re-signing stopped — suspended account, failed scheduled job, an incident at the DNS operator. The existing signatures age past their end date.

    What fixes it: Restore signing. Watch the signature end dates, not just whether DNSSEC is switched on: a signed zone with stale signatures is worse than an unsigned one.

  • A key roll left the old digest behind

    What causes it: The key was replaced in the zone, but the digest published at the registry still names the old one.

    What fixes it: Publish the new digest, let both sit side by side while caches drain, then remove the old one.

  • Only some visitors are affected

    What causes it: It is not a display bug: only validating resolvers refuse the answer. The others serve the zone without checking anything.

    What fixes it: Test against a validating resolver instead of from your usual machine. It is the only way to see the outage your visitors are seeing.

The questions that come next

Does DNSSEC encrypt my DNS queries?

No. It authenticates them: you know the answer is the right one, but it still travels in the clear and anything on the path can read it. Encrypting queries is a separate matter, handled by DNS over HTTPS or DNS over TLS.

Should DNSSEC be turned on for a brochure site?

It is a judgement call. The gain is real but invisible day to day; the risk is a total, silent outage if re-signing stops. Turn it on when the zone sits with an operator that rolls keys automatically, and when someone is watching the end dates.

Does my extension support DNSSEC?

Most common extensions accept it, but not all, and the registrar also has to know how to pass the digest up. Without that relay, a zone can be signed with nobody able to verify it: to the rest of the world it stays unsigned.

How long does a signature stay valid?

It depends on the operator doing the signing: each signature carries its own end date, and the operator renews it well in advance. What matters is not the lifetime chosen but that the renewal keeps running.

A DNSSEC failure makes no noise

No browser warning, no error message, just a domain that stops existing for part of the internet. DomainVigil queries every domain you own each day and emails you when an answer stops being served.

Start for free

Five domains free, forever. No card required.

The other reference guides