Enable DNSSEC: setup and checks with dig

DNSSEC earned a bad reputation in its early years: complicated, fragile, and if something went wrong the domain disappeared. Today, switching it on is a single setting at most DNS providers and checking takes two minutes. If you want to enable DNSSEC, there are really two things to understand: where the key lives, and what happens when you change provider.

What enabling DNSSEC actually means

Ordinary DNS answers aren’t signed. A resolver asks “what’s the IP for example-shop.com?” and believes whatever comes back. With DNSSEC, every answer from your zone carries a cryptographic signature, and a validating resolver checks it.

To know which key to trust, the resolver follows a chain:

If your DNS provider signs the zone but there is no DS record in the .com zone, the middle link is missing. The signatures exist, but nobody checks them. That half-finished state is the most common one.

Enable DNSSEC in four steps

1. Sign the zone. Your DNS provider’s dashboard usually has a DNSSEC switch. The provider generates a zone-signing key (flag 256) and a key-signing key (flag 257) and signs every record. If DNS and registration sit with the same company, it often handles step 2 automatically.

2. Publish the DS record. The public part of the key-signing key has to reach the parent zone. For .com and most other extensions your registrar submits a DS record, which is a hash of that key. Your DNS provider shows you the values: key tag, algorithm, digest type and digest. A few registries, such as DENIC for .de, take the DNSKEY itself and compute the DS record on their side.

3. Verify. More on that below.

4. Write it down. Note who holds the keys. When you change DNS provider in two years, you’ll need it.

Checking DNSSEC with dig

This query shows whether a DS record exists in the parent zone, here for cloudflare.com:

dig DS cloudflare.com +short

2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9

The fields are: key tag 2371, algorithm 13 (ECDSAP256SHA256), digest type 2 (SHA-256), then the digest. If your own domain returns nothing, there is no DS record and the chain is open.

The ad flag tells you whether a validating resolver accepts your answers:

dig +dnssec cloudflare.com A @1.1.1.1

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
cloudflare.com.   22  IN  A      104.16.133.229
cloudflare.com.   22  IN  RRSIG  A 13 2 300 20261019164432 20261017144432 34505 cloudflare.com. JscMk...

ad stands for authenticated data: the resolver checked the signature and found it valid. The RRSIG line is the signature, with expiry and inception timestamps.

To see what failure looks like, query a test domain that is deliberately signed wrong:

dig A dnssec-failed.org @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14211

Adding +cd (checking disabled) still returns an IP. That’s how you diagnose a DNSSEC fault on your own domain: SERVFAIL without +cd and a correct answer with it means the chain is broken.

The risky moment: changing DNS provider

Almost every DNSSEC outage happens during a move to a new DNS provider. The new provider signs with new keys, but the registry still holds the old DS record. Once the nameservers switch, keys and signatures no longer match and validating resolvers return SERVFAIL.

There are two safe ways:

1. Disable, move, enable. Remove the DS record at the registrar, wait until the DS record’s TTL has expired (in .com that’s a day), switch nameservers, then turn DNSSEC on at the new provider and publish the new DS record. In between the domain is unsigned but reachable.
2. Both keys in parallel. Publish the new provider’s DS record alongside the old one before switching nameservers. This only works if both providers cooperate.

For most people, option one is simpler.

What DNSSEC makes possible

DNSSEC also underpins other mechanisms. The best known is DANE: you publish a TLSA record that states which certificate your mail server uses. A sending server that supports DANE checks the certificate on delivery and refuses to fall back to an unencrypted connection. DANE for SMTP is specified in RFC 7672, and without a signed zone a TLSA record would be worthless, because anyone able to forge DNS could forge it too.

Signatures also expire. Good DNS providers re-sign automatically; if you run your own nameservers with BIND or Knot, make sure automatic re-signing works, because expired signatures cause the same SERVFAIL as a wrong key.

What DNSSEC protects and what it doesn’t

DNSSEC protects answers between your nameservers and a validating resolver. Forged answers from cache poisoning or redirected traffic get caught. The scenarios are described in DNS hijacking.

What it doesn’t stop: someone with your login editing the zone itself or switching DNSSEC off. Two-factor login and, for important domains, a registry lock cover that.

DNSSEC at betadomain

DNSSEC is part of what betadomain offers. For a .com domain with DNSSEC the process is the one above: sign the zone, publish the DS record, verify with the commands shown. The same applies to .net and other signed extensions. If you manage many domains, you can automate it through the domain API.

A first step takes one line: dig DS yourdomain.com +short. If nothing comes back, you know what to do.

Step by step

1. Sign the zoneSwitch on DNSSEC at your DNS provider, which generates keys and signs your records.
2. Publish the DS recordAdd the DS record (or DNSKEY, depending on the registry) at your registrar, which sends it to the registry.
3. Verify with digUse dig DS and dig +dnssec to confirm the DS record exists in the parent zone and answers carry the ad flag.
4. Plan provider changesBefore switching DNS provider, remove the old DS record or add the new provider's key in advance.