DNS was designed without any way to check that an answer is genuine. A resolver asks a question and trusts whatever reply arrives, which leaves room for attackers to inject forged answers and send users to the wrong server. DNSSEC, the DNS Security Extensions, fixes that by adding digital signatures to DNS data. A resolver that validates DNSSEC can confirm that an answer really came from the zone's owner and was not changed along the way. The core specifications are RFC 4033, RFC 4034 and RFC 4035.
What DNSSEC does and does not do
DNSSEC provides authenticity and integrity: proof that records are the ones the zone publisher signed, and proof that a name or record type genuinely does not exist when the server says so.
It does not provide confidentiality. Queries and answers are still visible on the network; encrypting them is the job of separate technologies such as DNS over TLS or DNS over HTTPS. DNSSEC also does not protect your website or email directly. It protects the DNS answers that point people to them.
The building blocks
DNSSEC introduces a few new record types.
RRSIG: the signatures
Records of the same name and type are grouped into a record set, and each set is signed. The signature is published as an RRSIG record alongside the data. Every RRSIG has an inception and expiration time, so signatures must be refreshed regularly; a zone whose signatures lapse will fail validation just as surely as one with forged data.
DNSKEY: the zone's public keys
The public keys used to check signatures are published in the zone as DNSKEY records. Most zones use two roles:
- Zone signing key (ZSK): signs the ordinary records in the zone. It is often rolled more frequently.
- Key signing key (KSK): signs only the DNSKEY record set. It is the key that the parent zone vouches for. In DNSKEY records, the KSK usually carries flag value 257 and the ZSK 256.
Some setups use a single combined key for both roles, which is perfectly valid.
DS: the link to the parent
The delegation signer (DS) record is the crucial piece. It contains a hash of your KSK and is published in the parent zone, not in your own. For example.com, the DS record lives in the .com zone. You submit it through your registrar, which passes it to the registry.
example.com. 86400 IN DS 31589 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE6A3D0B4E3C1E4A5F0B2C7D8E
The fields are the key tag, the algorithm (13 is ECDSA P-256 with SHA-256), the digest type (2 is SHA-256) and the digest itself.
NSEC and NSEC3: proving non-existence
To prove a name does not exist, a signed zone returns NSEC or NSEC3 records that show the gap between existing names. NSEC3 uses hashed names to make it harder to list every name in the zone.
The chain of trust
Signatures only help if the resolver can trust the key that made them. DNSSEC solves this with a chain running down from the root:
- Validating resolvers ship with the root zone's key configured as a trust anchor.
- The root zone contains a signed DS record for .com, which vouches for .com's KSK.
- The .com zone contains a signed DS record for example.com, which vouches for example.com's KSK.
- example.com's KSK signs its DNSKEY set, which includes the ZSK.
- The ZSK signs the actual records, such as the A record for www.example.com.
If every link checks out, the answer is secure. If a zone has no DS record at its parent, the chain simply ends there and the answer is insecure, meaning unsigned. That is not an error; it is how many domains operate. The root and most TLDs are signed, but each individual domain has to opt in.
Validation results
A validating resolver classifies each answer:
- Secure: the full chain validated.
- Insecure: there is proof that the zone is not signed, so the answer is accepted without DNSSEC protection.
- Bogus: the zone is supposed to be signed, but validation failed. Signatures might be expired, keys might not match the DS record, or the data might have been tampered with.
A validating resolver will not hand a bogus answer to clients. It returns SERVFAIL instead. To users of that resolver, the domain simply stops working, while users of non-validating resolvers may see no problem at all. That split is a strong hint that DNSSEC is the cause.
The AD bit
When a validating resolver has confirmed an answer as secure, it sets the AD (authenticated data) flag in its response. You can see this with command-line tools:
$ dig +dnssec www.example.com A
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
The ad flag means the resolver you queried validated the answer. Note that you are trusting that resolver's judgment, and the path between you and it, which is why the bit is most meaningful when the resolver is local or reached over a secure channel. Setting the CD (checking disabled) flag in a query asks the resolver to skip validation, which is useful for diagnosis: if a name returns SERVFAIL normally but resolves with CD set, the failure is almost certainly DNSSEC-related.
The most common failure: a stale DS record
By far the most frequent way a domain breaks with DNSSEC happens during a move between DNS providers:
- The domain is signed at provider A, and the registrar holds a DS record matching provider A's key.
- The owner switches nameservers to provider B, which either does not sign the zone or signs it with different keys.
- Nobody removes or updates the DS record at the registrar.
The parent now says "this zone is signed with key X," but the new servers publish no key X. Validating resolvers mark every answer as bogus and return SERVFAIL. The website, email and anything else on the domain fail for a large share of users.
To avoid this, before switching providers either remove the DS record and wait for its TTL to pass, or coordinate a proper key rollover so the parent and the new provider agree at every step. If you find a domain in this state, the fix is to update or remove the DS record at the registrar. See Understanding nameservers for the wider migration checklist.
Other failure causes include signatures that expire because re-signing stopped, and a key rollover performed without updating the DS record in time.
Check it yourself
- DNSSEC Checker follows the chain of trust from the root to your domain, checks the DS and DNSKEY records match, and reports whether answers validate as secure, insecure or bogus.
- DNS Lookup lets you look at DS, DNSKEY and RRSIG records directly.