DNSSEC

Your resolver asks example.com for an A record. A value comes back. How do you know it came from the authoritative server and not from something on the network between?

Without DNSSEC, you don't. UDP is forgeable. Caches are poisonable. DNS has been lied to since it was invented.

DNSSEC fixes this by signing DNS responses. A validating resolver can check the signature. If it doesn't verify, the resolver returns SERVFAIL and your application cannot talk to a poisoned answer.

The problem

DNS responses were plain text with no authentication until 2005. Kaminsky's 2008 cache-poisoning attack made the risk operational: an attacker injecting a crafted response fast enough could make a resolver cache it, sending every user of that resolver to an IP the attacker controlled.

Stopgaps helped: source-port randomisation, 0x20 case randomisation, EDNS cookies. None of them are authentication. They make guessing harder, not impossible. DNSSEC authenticates.

The idea

Every record set in a signed zone has a matching RRSIG (signature). Your zone's public key lives in a DNSKEY record. The parent zone (your TLD) publishes a DS record that names the hash of your DNSKEY. The root zone is the trust anchor. Every validating resolver ships with its public key.

Specified in RFC 4033 (introduction), RFC 4034 (records), and RFC 4035 (protocol).

The chain

DNSSEC is a chain walking top-down. Each link names the public key of the next.

The DS handoff

Here is the single thing most DNSSEC deployments get wrong. You sign your zone. You publish DNSKEY, every RRSIG, the NSEC3 chain. You forget to submit the DS record to your registrar. The parent (.com) does not point at your key. The chain of trust breaks at your zone, and every resolver treats you as unsigned.

Toggle the DS button above. The left panel is what your registrar publishes. The right panel is what your DNS provider publishes. Both must be present and must match. The DS submission is usually a form in your registrar's dashboard; if it is not there, your registrar does not support DNSSEC and you will need to move before you can sign.

Algorithms

RFC 8624 is the current implementation guidance. New deployments: ECDSA P-256. Future default: ED25519. Everything older than SHA-256 is a liability.

If you are signing today, code 13 is the default answer. Smaller keys than RSA, faster to verify, universal support in modern resolvers.

Authenticated denial

A signed response for "this name does not exist" is a trickier problem: you cannot sign something that does not exist. DNSSEC handles it with two mechanisms.

Most zones use NSEC3 today. Specified in RFC 5155.

Key rollover

Keys wear out. You rotate them. DNSSEC splits your signing key into two kinds:

• ZSK (zone-signing key). Signs record sets. Rotate frequently (every 30-90 days is common). Rolling it never touches the parent zone.
• KSK (key-signing key). Signs the DNSKEY record set (which includes the ZSK). Rotate less often (every 1-3 years). Rolling it means updating the DS at the registrar.

The ZSK/KSK split exists because DS updates at the registrar are slow and error-prone. Keep the KSK stable. Rotate the ZSK on a cron job.

What DNSSEC is not

• Not confidentiality. Responses are still in the clear. For that you want DoT or DoH.
• Not DDoS protection. It actually makes amplification easier. Use rate limiting and anycast.
• Not universal. About 30% of domains are signed. About 30% of resolvers validate. The browser does not validate directly; your recursive resolver does.

Common mistakes

Check whether your zone is signed, whether the DS matches, and whether signatures are fresh: scan your domain. Sudory walks the chain from root to your zone and tells you exactly where it breaks.