DNSSEC in plain language

Module 8: Security and troubleshooting · Reading time: 11 minutes

Learning objective: After this lesson, you can explain in plain language what DNSSEC protects, how the chain of trust works, and why it can go wrong during a transfer.

Key concepts: DNSSEC, signature (RRSIG), key (DNSKEY), DS record, chain of trust, validating resolver, SERVFAIL

The problem: how do you know an answer is genuine?

In module 1 you saw that a resolver asks a series of questions: to the root, to the TLD server, and to the authoritative nameserver. The answer that comes back is trusted and cached. But ordinary DNS doesn't check whether that answer really comes from the right nameserver. An attacker who manages to send a fake answer before the real one arrives can make a resolver believe that example.com lives at 203.0.113.66 instead of 192.0.2.10. This is called cache poisoning: the cache is "poisoned" and everyone using that resolver ends up on the wrong server.

DNSSEC (DNS Security Extensions) solves this by signing answers. The resolver can then check whether an answer is genuine and hasn't changed in transit.

What DNSSEC does and doesn't do

This is the most important thing to remember:

A signature works like a seal on an envelope: anyone can read the letter, but you can immediately see if someone has opened it.

The three parts

DNSSEC adds a few record types. You don't need to create them yourself (your DNS manager or panel does that), but you will come across them:

• DNSKEY: the public key of the zone. This lets anyone check the signatures.
• RRSIG: the signature attached to a group of records. Every A, MX, or TXT answer gets an RRSIG with it. A signature has a start and end date, so the zone needs to be re-signed regularly.
• DS (Delegation Signer): a short "fingerprint" of your zone's key. It's not in your own zone, but with the parent: for example.com that's with the registry of .com (Verisign), for a .nl domain it's with SIDN (the registry of .nl in the Netherlands).

Here's what a signed answer looks like (shortened):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

In the RRSIG you can see, among other things, the algorithm (13 = ECDSA P-256 with SHA-256), the end date (19 November 2026), the start date, and the key number (30794).

The chain of trust

Why is the DS kept with the parent? Because a key inside your own zone proves nothing: an attacker could just as easily include their own key. That's why the check runs from top to bottom:

1. The resolver trusts the key of the root. It's built into every validating resolver (the trust anchor).
2. The root has a DS for .com, signed with the root key. This tells the resolver which key .com is supposed to have.
3. The .com zone has a DS for example.com, signed with the .com key.
4. The zone example.com has a DNSKEY that matches that DS, and with it all the RRSIGs can be checked.

Each link proves the next one. If one link breaks, the entire chain becomes untrustworthy.

A validating resolver (most large public resolvers, and an increasing number of providers) follows this chain. If it checks out, you get the answer. If it doesn't check out, the resolver gives no answer, but the error status SERVFAIL. To the visitor, the site then simply looks like it "doesn't exist", even though your records might be perfectly fine.

You can see this for yourself with a domain that's been deliberately broken:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

With +cd ("checking disabled") you ask the resolver to skip the check. If you then get an answer, you know for certain that DNSSEC is the cause:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

A domain without DNSSEC (no DS with the parent) doesn't produce a SERVFAIL: it's simply unsigned and is passed through as "insecure".

Where it goes wrong: transfers and key rollovers

DNSSEC itself almost never breaks on its own. It goes wrong when the DS at the registry no longer matches the key in the zone. This happens mainly:

• During a transfer of nameservers or DNS provider. The new provider signs with its own key, but the registry still has the DS of the old provider. Result: SERVFAIL for everyone with a validating resolver. This is the classic mistake after a transfer.
• During a key rollover where the new DS hasn't been sent to the registry (in time).
• When signatures expire, because the zone is no longer being re-signed.

The safe order for a transfer is therefore:

1. Remove the DS from the registry (or have the new provider supply a DS that you add).
2. Wait until the TTL of the old DS has passed.
3. Switch the nameservers.
4. Turn on DNSSEC with the new provider and have the new DS placed at the registry.

Many registrars and panels nowadays handle this automatically as long as the domain and DNS are with the same provider. If they're with different providers, you need to transfer the DS yourself.

Checking it yourself: DNSViz, Zonemaster and internet.nl

You don't need to trace the chain with dig. There are free tools that do it for you and show the result.

DNSViz (https://dnsviz.net/) draws the whole chain as a diagram. Here's how to use it:

1. On the front page, type the domain name into the search box (just the name, without https:// and without www) and click Go.
2. DNSViz shows the latest analysis. If it's old, or you've just made a change, click Update now. After a few seconds, you'll see the diagram.
3. Read the diagram from top to bottom: the root (.) at the top, the TLD below it (for example nl), your domain at the bottom. Each zone is a box.

What you see in the diagram:

You follow the chain like this: the DS (held by the parent) points to the DNSKEY (in your zone), and that DNSKEY uses an RRSIG to sign the records. That's exactly the chain from this lesson, drawn out.

The colours tell you whether it's correct:

• Blue: secure. The chain runs unbroken from the root to this part.
• Black: insecure (unsigned). There's no DS, so there's nothing to check. That's not an error, the domain simply doesn't use DNSSEC.
• Red: bogus. A DS doesn't match a key, or a signature is incorrect. A validating resolver will then give a SERVFAIL.
• Purple (on a signature): the signature has expired or isn't valid yet. The zone is no longer being re-signed.
• Yellow: a warning, for example a nameserver that's not responding properly, or an algorithm the tool doesn't recognise.
• Grey and dotted: a key is being referenced that doesn't exist. If you see a dotted DNSKEY under a DS, the parent still holds a DS for an old key: the classic mistake after a transfer.

Next to a part there may be a small triangle (warning) or a round error symbol. Hover over it with your mouse, or check the list below the diagram: it explains in words what's wrong.

Try it out with sidn.nl (all blue) and with dnssec-failed.org (red, with a dotted key below the DS).

Other tools that look at the same thing from a different angle:

• Zonemaster (https://zonemaster.net/): checks your whole zone the way a registry would, including DNSSEC. The result is a list with green (good), orange (warning) and red (error).
• internet.nl (https://internet.nl/): the website and email test show, among other things, whether DNSSEC is correctly set up for your domain and your mail servers, with green ticks or red crosses.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): works through the chain step by step and puts a green tick or a red cross at each step. Handy when you're looking for one specific fault.

Use them after every change to DNSSEC, and certainly before and after a transfer. Let the tool re-analyse if needed: these tools also work with caches and TTLs.

In practice: what it looks like in a panel

In My WebOké you turn on DNSSEC for a domain under DNSSEC/DANE; the panel creates the keys and sends the DS to the registry. In DirectAdmin and with external providers such as Cloudflare it's usually called "enable DNSSEC"; Cloudflare then shows you a DS record that you need to enter yourself at your registrar. Other panels work in a similar way: there's always a step "create keys" (with the DNS provider) and a step "DS at the registry" (with the registrar).

Summary

• DNSSEC signs DNS answers so a resolver can check they're genuine. It doesn't encrypt anything.
• DNSKEY is the key, RRSIG is the signature, DS is the fingerprint held by the parent.
• The check runs as a chain from the root to your domain. If a link breaks, a validating resolver gives a SERVFAIL.
• Almost all problems arise because the DS at the registry no longer matches, often after a transfer.
• With dig +cd you can see whether a problem is caused by DNSSEC.
• DNSViz draws the chain: blue is secure, black is unsigned, red is bogus. Zonemaster, internet.nl and the Verisign DNSSEC Debugger are good second opinions.

Quiz

Exercise

Exercise Z8.1: Seeing DNSSEC. Find out which of two domains has DNSSEC working correctly and which has been deliberately broken: sidn.nl and dnssec-failed.org. Look up the DS record and the A record for both via a validating resolver (for example 1.1.1.1 or 9.9.9.9), using dig or an online tool. Fill in: the key number (key tag, the first number) of the DS for sidn.nl, and the status you get for dnssec-failed.org.

Exercise Z8.1b: Reading DNSViz. Analyse nlnetlabs.nl in DNSViz (https://dnsviz.net/, type in the name and click Go; click Update now if the analysis is old). Read the diagram and fill in: (1) the status of nlnetlabs.nl (secure, unsigned or bogus), (2) the algorithm number of the DNSKEY records (shown in every oval as alg=), (3) how many DNSKEY ovals appear in the zone of nlnetlabs.nl, (4) the key number (id=) of the filled grey DNSKEY that the DS points to, and (5) the status DNSViz gives for dnssec-failed.org. The check retrieves the same data live.

Exercise O8.1: Assessing three DNSSEC demo zones. We've set up three demo zones: signed-demo.dnspractice.com (correct chain), broken-demo.dnspractice.com (deliberately broken) and unsigned-demo.dnspractice.com (unsigned). Find out for each zone whether it's secure, bogus, or unsigned, for example using DNSViz or dig +dnssec (watch for the AD flag, and if you get a SERVFAIL, also try +cd). Choose your answer for each zone below.

Further reading

These articles describe the steps in WebOké's panels; with other providers the buttons may be named differently.

• WebOké manual 5.8: DNSSEC and DANE
• What is DNSSEC?
• Activate DNSSEC
• Website or email not working after a move or DNS change: check your domain