DNSSEC Explained: How DNS Gets Cryptographically Signed

Ordinary DNS has no way to prove an answer is genuine. A resolver asks a question and trusts whatever answer comes back, which leaves room for an attacker in the right position on the network to forge a response and redirect a visitor without either the domain owner or the visitor ever seeing anything wrong. DNSSEC adds a cryptographic signature to DNS records, letting a resolver verify an answer actually came from the legitimate holder of that zone.

A domain's own DNSKEY record signs its records, but that alone only proves the records are internally consistent, not that the key itself is legitimate. The chain is completed by a DS record published at the parent zone, the domain's registry, which vouches for the domain's key. A resolver walks this chain from the root down through the top level domain to the domain itself, and only trusts the final answer if every link along the way checks out.

Setting up DNSSEC correctly at a DNS provider generates a DNSKEY, but that key does nothing on its own until the corresponding DS record is also published at the domain's registrar, a separate step that is easy to forget since it happens in a different place entirely. A domain with signed records but no DS record at the registrar isn't validated by anything, it's simply DNSSEC-capable but not actually protected.

A validating resolver marks a successfully verified response with an AD flag, short for Authenticated Data, in its reply. This is the definitive signal that DNSSEC is not just configured but actually working end to end for a given query, as opposed to just checking whether DNSKEY records exist, which only confirms the domain attempted to set it up.

DNSSEC Checker queries a validating public resolver directly and reports both whether DNSKEY records exist and whether that resolver's AD flag confirms the chain of trust actually validated, which is a much more reliable answer than assuming DNSSEC works just because a setting was switched on somewhere.