DNSSEC Explained: How the Chain of Trust Works, What a Validating Resolver Checks and How to Check It

What DNSSEC proves, and what it never hides

RFC 4033 lists three services. Data origin authentication shows a record was published by the zone that owns it. Data integrity shows nobody changed it on the way. Authenticated denial of existence lets a resolver prove that a name or record type really does not exist, so an attacker cannot fake a “no such domain” answer either.

The same RFC is just as clear about the limits. By deliberate design, the extensions do not provide confidentiality, and they do not protect against denial of service. Every signed query and answer still crosses the network in plain text, so anyone on the path can read which names you look up. Encrypted transports fill that gap.

That distinction trips up a lot of comparisons. Authentication answers “is this data genuine?” Encryption answers “who can read this?” A signed answer delivered over plain UDP is genuine but public. An encrypted answer from a resolver that never checked signatures is private but only as trustworthy as that resolver. The encrypted DNS overview covers the second half.

The chain of trust, from the root down

Signatures are worthless unless you trust the key that made them. RFC 4033 solves that with a chain of trust. A resolver starts with at least one trust anchor, a key it knows in advance, normally at the root. Each zone vouches for the next one down, using four record types that RFC 4034 defines:

• DNSKEY holds a zone’s public keys.
• RRSIG holds the signature over a set of records of the same name and type.
• DS (delegation signer) sits in the parent zone and contains a hash of the child’s key, linking parent to child.
• NSEC proves that a name or type does not exist, signed like everything else.

A resolver checking www.example.org therefore walks a path: the root’s DNSKEY verifies the DS for org, which matches the DNSKEY of org, which verifies the DS for example.org, and so on until the RRSIG on the final record checks out. A single missing or expired link breaks the chain of trust, and the answer becomes bogus.

What a validating resolver does with the result

A validating resolver performs that walk on your behalf. RFC 4035 sets the rules for reporting the outcome. The resolver may set the AD (Authenticated Data) bit only when it considers every record set in the answer and authority sections authentic. Stub resolvers on laptops and phones normally do not check signatures themselves; they rely on that single bit.

When validation fails, the rule is strict. For bogus data on a recursive query, the server must return RCODE 2, server failure, instead of the broken answer. The one exception is a query with the CD (Checking Disabled) bit set, which tells the validating resolver that the client does its own checking and wants the raw data.

How to check DNSSEC with dig

BIND’s dig makes the bits visible. Adding +dnssec sets the DNSSEC OK (DO) bit, so the server returns the signature records with the answer. The flags line at the top of the output shows ad when the resolver validated the data. According to the BIND manual, dig sets the AD bit in the query by default.

Run the query twice to learn more. First ask a validating resolver, for example dig +dnssec example.org @9.9.9.9, and look for ad in the flags and RRSIG lines in the answer. Then add +cd to switch validation off. If a name returns SERVFAIL normally but resolves with +cd, its signatures are broken and the refusal was correct.

Resolvers that check signatures

On a Linux machine running systemd-resolved, the DNSSEC= option in resolved.conf decides whether the local stub validates too. yes validates every lookup locally, allow-downgrade validates only when the upstream server supports it, and no skips it. The default is allow-downgrade, and the manual itself warns that this mode is open to downgrade attacks.

Why DNSSEC and DNSCrypt belong together

DNSCrypt and signature validation protect different stretches of the path. DNSCrypt encrypts and authenticates the hop between your machine and the resolver, so nobody on the local network can read or forge that answer. Signatures protect the data from the domain’s servers to the resolver. The DNSCrypt FAQ pairs the two for that reason.

The FAQ is also frank that signing has seen limited adoption and does not stop traffic from being monitored. Many domains are simply unsigned, and for those validation adds nothing. That is why encryption is the baseline and signature checking the second layer, rather than the other way round. The comparison table shows both properties for every protocol.

dnscrypt-proxy lets you combine them in one line. Setting require_dnssec = true in its configuration keeps only resolvers that support the extensions in the server list, and the example file recommends validating resolvers for bootstrap too. One caveat from the same file: if dnsmasq sits in front of the proxy and you use filtering, switch off dnsmasq’s own dnssec option.

When a signed domain fails to resolve

A sudden SERVFAIL on one domain, while everything else works, is the classic sign of a signing mistake there: an expired RRSIG, or a DS in the parent zone that no longer matches the child’s DNSKEY. Test with +cd as described above. If the name resolves with checking disabled, the fault sits with the domain operator, not your setup.

Resist the urge to switch validation off globally to make one site load. Use a non-validating resolver only for that test, report the problem to the domain owner, and keep checking enabled for everything else. To find DNSCrypt resolvers that validate, filter the resolver directory, and read the DNS spoofing page for the attacks this layer stops.