DNS and transport
DNSSEC in plain terms: what it protects and what it does not
DNSSEC makes forged DNS answers detectable. It does not make anything private. Here is the chain of trust, the common misconfigurations, and the failure modes.
What DNSSEC actually does
DNSSEC adds cryptographic signatures to DNS records. A validating resolver can then tell whether an answer it received is the answer the zone owner published, or something injected along the way.
It does not encrypt DNS queries. Anyone on the path can still see that you looked up a name. What they cannot do, with DNSSEC in place and validated, is quietly substitute a different answer.
The chain of trust
Each zone signs its records with a private key and publishes the signatures (RRSIG). The parent zone publishes a delegation signer record (DS) containing a digest of the child's key. A resolver starts at the root trust anchor and walks down, verifying each link.
If any link is missing, the zone is treated as unsigned. If a link is present but the signature does not validate, the answer is bogus and the resolver should return SERVFAIL rather than the forged data. That failure mode is the point: a broken DNSSEC deployment makes names unresolvable for validating resolvers, which is worse than no DNSSEC at all.
The most common operational mistake is a key rollover where the DS record at the parent was never updated. The second most common is an expired signature because a signer stopped running.
What it does not protect
DNSSEC does not protect the web server, the TLS certificate, or the application behind the name. It does not prevent a domain owner from publishing malicious records, and it does not stop a registrar account takeover — the attacker simply publishes new, validly signed records.
It also does not improve privacy. For that, a separate mechanism (DNS over TLS or HTTPS) is required, and it protects the transport rather than the content.
Why a small business might care
The records that matter most are the ones that direct where mail goes and where authentication happens. A forged MX or TXT answer can redirect or defeat mail authentication for a domain that otherwise looks well configured.
DNSSEC is not free: it requires a registrar that supports DS records, a DNS host that signs zones, and a process for monitoring expiry. That cost is why it is often skipped — and why it is worth noting when it is present.
How it is assessed externally
An external check looks at whether the zone publishes signed records, whether the parent publishes a DS record, and whether validation succeeds through a validating resolver. It cannot see private keys, and it does not attempt to.
SMB Scanner Lite reports this as control C02, with the evidence line naming the validation path that succeeded. In the recorded assessment the evidence reads Zone signed with validated RRSIG and parent DS delegation.
If you are implementing it
Enable signing at your DNS host first, confirm the zone answers correctly, then add the DS record at the registrar. Monitor signature expiry. Decide in advance what you will do if validation breaks, because the answer cannot be "disable DNSSEC quickly" without accepting that resolvers will fail closed.
Read the related controls in the capability catalog, particularly CAA and zone transfer exposure, which address adjacent parts of the DNS trust story.
See how this is measured. SMB Scanner Lite evaluates these controls from outside and attaches the observation behind every conclusive finding. Browse the 22-control catalog or inspect the recorded assessment.
The practical version
This article explains the mechanism. The blog covers the sequence: what to check, in what order, and what to do with the answer.