Why should you use DNSSEC?

January 22, 2020 by Jonas Lejon
Why should you use DNSSEC?

Did you know the Domain Name System (DNS) is entire plain text and subject to man-in-the-middle attacks? In fact, that’s what a lot of large ISPs are doing worldwide to intercept DNS traffic and re-route websites.

Luckily, there’s a solution. By introducing cryptographically signed DNS records (also known as “DNSSEC”) you can still verify and validate that DNS records haven’t been tampered with.

DNS still remains as plain text, by by introducing the concept of “checksums” and validations, you can at least make sure the DNS records you (or your browser) are requesting are the original ones and not modified.

How does DNSSEC work?

But how can a plain text system offer this kind of protection?

It does so by digitally signing every DNS record using public-key cryptography. The same kind of cryptography used in SSL-certificates, SSH-keys, …

The use of DNSSEC introduces several new resource records in DNS: RRSIG, DNSKEY, DS & NSEC3.

You might already know A, CNAME, MX, … the resource records above are similar, but they serve a very specific purpose: signing DNS records.

Just like DNS itself, the validation follows a chain of trust. A hierarchy.

You can see this in practice if you use dig with the +trace and +dnssec flag.

$ dig +dnssec +trace dnssec-tools.org | grep -P '(RRSIG|DS|DNSKEY)'

Its output will be … confusing. The good news is, it isn’t for humans to read – it’s for computers to verify.

What does DNSSEC solve?

By introducing cryptography in DNS, we can now verify that every record we have received is the _correct_ record.

Just like SSL or SSH keys, the private part of the cryptography stays on the nameserver. Its used to sign the records. We can just the public keys, as published in DNS, to verify that they remain unchanged.

If a man-in-the-middle (either an ISP or a malicious actor) would change a DNS record, the DNSSEC signatures would fail.

The result will be that your nameserver will consider this a DNS resolve failure, and you’d see a ERR_NAME_NOT_RESOLVED error in your browser.

Sure, your nameserver received a reply, but it couldn’t be proven that it was legitimate and will therefore not be served to your clients.

Guest blog post by Mattias Geniar