What Is DNSSEC?

What DNSSEC actually is

DNSSEC, short for DNS Security Extensions, is a set of additions to ordinary DNS that let a domain cryptographically sign its records. Each signed answer carries a digital signature the domain produced with a private key only it holds, and a resolver can check that signature against the domain's matching public key. Alter the answer by even one character and the signature stops matching, so the check fails. In short, it adds authenticity and integrity to a system that originally had neither: a way to prove an answer is real and unchanged.

One thing it never does: encrypt. DNSSEC signs. Lookups and answers stay fully readable to anyone on the path; they just can no longer be forged without being caught.

Why it is needed

Plain DNS was designed in a more trusting era and has no way to prove an answer is genuine. When a resolver asks for a name and an address comes back, nothing in classic DNS shows whether that address truly belongs to the domain or was slipped in by someone in between. That gap is not theoretical.

The clearest example is cache poisoning. A resolver stores answers briefly so it can reply quickly, so if an attacker manages to inject a forged reply before the real one arrives, the resolver caches the forgery and then serves it to everyone who asks next. Aim that at a domain people rely on, a bank, an email provider, a software update server, and ordinary users are quietly sent to an impostor that looks identical while the address bar still shows the correct name. Passwords are entered, updates are swapped, and nothing appears wrong.

Encryption alone does not close this. Encrypted DNS protects the link between you and your resolver, but it says nothing about whether the records themselves are real. DNSSEC fills that gap: because each record is signed and the signatures chain back to the root, a forged answer simply fails validation.

How the chain of trust works

Every signed zone holds a key and signs its own records with it, producing a signature record alongside each answer. On its own a signature proves nothing, because anyone can sign anything. What makes it trustworthy is that the parent zone vouches for the child's key: the root vouches for the key of .com, .com vouches for the key of example.com, and example.com signs its own records.

That hand-off mirrors the same hierarchy a resolver already walks to find a name. A validating resolver starts from one fact it trusts absolutely, the root's public key, known as the trust anchor, and follows the chain down. At each step it confirms the parent's vouch for the child, then checks the child's signature on the data. If every link holds, the answer is authentic. If any signature is missing or wrong, the resolver refuses to return it at all rather than serve something it cannot verify.

In record terms you may see these names: the key is published as a DNSKEY, each answer's signature as an RRSIG, and the parent's vouch for the child as a DS record. You never handle these yourself; the resolver does the checking on your behalf. They do have one visible side effect: signatures make answers much larger, which is the main reason a lookup falls back from UDP to TCP.

Check it yourself: three answers, one command

All of the above is visible from a terminal, and the whole story fits in one flag. A validating resolver sets ad - authenticated data - on any answer whose signatures it checked and trusted. Ask for a signed name:

$ dig @194.180.189.33 dnsdoh.art A +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52605
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Now run the same command against three different names and you get three different outcomes, which between them are the whole of DNSSEC:

That last one is a test domain that is deliberately broken, and the SERVFAIL is DNSSEC working exactly as intended. You can prove the failure is a validation decision rather than a dead server by telling the resolver to skip checking, with +cd - checking disabled:

$ dig @194.180.189.33 dnssec-failed.org A +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10019

$ dig @194.180.189.33 dnssec-failed.org A +cd +noall +answer +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59771
dnssec-failed.org.  299  IN  A  96.99.227.255

Same resolver, same name, one second apart. The record was there the whole time; validation was the only thing standing between you and it. That is the entire value proposition in two commands - and it is also the honest cost, because a zone whose signatures break through operator error goes dark for everyone rather than serving a wrong answer.

Seeing the chain itself

The three records named in the previous section can each be fetched directly. The DS record lives in the parent zone and is the parent vouching for the child's key; the DNSKEY is the key itself; the RRSIG is a signature over an actual answer:

$ dig @194.180.189.33 dnsdoh.art DS +short
39388 13 2 909C791465A1BC8E827673F22E0B6AE66F65274DEF5B51A9D9E78467...

$ dig @194.180.189.33 dnsdoh.art A +dnssec +noall +answer
dnsdoh.art.  299  IN  A      194.180.189.33
dnsdoh.art.  299  IN  RRSIG  A 13 2 300 20260918101536 20260827101536 4030 ...

The 13 in both is the algorithm, ECDSA on the P-256 curve. The two long numbers in the signature are its validity window, an expiry and an inception date - signatures are deliberately short-lived, which is why a signed zone needs working automation and not just a one-time setup. How that is run here is written up in Anatomy of a Hardened DNS Zone.

On Windows, where the tooling is better

DNSSEC is the one place where the built-in Windows tools have the advantage. PowerShell knows about validation, and the broken test domain surfaces as an ordinary error:

PS> Resolve-DnsName -Name dnssec-failed.org -Server 194.180.189.33 -DnsOnly
FAILED: dnssec-failed.org : Ошибка DNS-сервера.

PS> Resolve-DnsName -Name dnssec-failed.org -Server 194.180.189.33 -DnsOnly -DnssecCd
Name              Type TTL Section IPAddress
----              ---- --- ------- ---------
dnssec-failed.org A    252 Answer  96.99.227.255

-DnssecCd is the exact counterpart of dig's +cd, and the pair behaves identically: refused, then retrieved. The error text is written in the machine's display language, so yours will read differently from the line above; the behaviour is the same.

Where PowerShell genuinely beats dig is -DnssecOk. dig prints a signature as one long opaque line. PowerShell parses it:

PS> Resolve-DnsName -Name dnsdoh.art -Server 194.180.189.33 -DnsOnly -DnssecOk
Name        : dnsdoh.art
QueryType   : RRSIG
TypeCovered : A
Algorithm   : 13
LabelCount  : 2
OriginalTtl : 300
Expiration  : 18.09.2026 10:15:36
Signed      : 27.08.2026 10:15:36
Signer      : dnsdoh.art
Signature   : {2, 53, 141, 187…}

Every field dig crams into that one line, named and formatted. Algorithm 13 is the same ECDSA P-256, and the two dates are the same validity window shown as dates rather than as 20260827101536. Three weeks of life on a signature, which is the detail that tells you a signed zone is an ongoing commitment rather than a switch you flip once. Run both tools against the same name and the numbers match, which is a reasonable way to satisfy yourself that neither is lying to you.