NOOB2ROOT

Field Guide Network & DNS

DNSSEC

Digital signatures for DNS records. A validating resolver can prove an answer really came from the domain's owner and wasn't tampered with on the way.

#What it is

Plain DNS has no way to prove an answer is genuine. Anyone who can get between you and the DNS server, or poison a resolver's cache, can reply with a fake address and send you to the wrong server.

DNSSEC adds signatures. A domain owner signs their records, and each level of DNS vouches for the keys of the level below it: the root signs .com, .com signs example.com, and so on. That's the chain of trust. A validating resolver, like my Unbound, checks every link in the chain.

#What validation looks like

  • Signed and valid: the answer comes back with the ad (authenticated data) flag set.
  • Signed but broken or tampered: the resolver returns SERVFAIL and gives you nothing. That's the point: no answer beats a forged one.
  • Not signed at all: the answer comes back normally, without ad. Plenty of domains still don't sign.

#Test it yourself

With dig, against your own resolver:

dig dnssec.works @127.0.0.1 -p 5335          # NOERROR, "ad" in the flags line
dig fail01.dnssec.works @127.0.0.1 -p 5335   # SERVFAIL: validation is working

Seeing SERVFAIL on the deliberately broken domain is good news.

#What it doesn't do

DNSSEC proves authenticity, not privacy. The questions and answers are still readable on the wire. Encryption is a different job (DNS-over-TLS or DNS-over-HTTPS).

← All Field Guide entries