TR
← Back to blogGuides

What Is DNSSEC? How It Works and How to Enable It Safely

What DNSSEC is, how signatures, DNSKEY and DS records form a chain of trust, what it does not protect, how to enable it, and how to avoid an outage.

Published: · 7 min read

Classic DNS has no way to prove that an answer is genuine. A resolver sends a question over UDP and believes the first plausible reply. Anyone who can inject or alter that reply (through cache poisoning, a compromised network or a rogue resolver) can send users to a different server. DNSSEC, the DNS Security Extensions, closes that gap by adding digital signatures to DNS data, so that a resolver can verify that an answer really comes from the zone's owner and has not been changed on the way.

It is worth enabling on most domains, and it is also one of the few DNS features that can take a domain completely offline if handled carelessly. Both halves are covered below.

What DNSSEC does, and what it does not

It provides:

  • Origin authentication and integrity: the records were published by whoever holds the zone's keys, and were not modified.
  • Authenticated denial of existence: a signed proof that a name or record type does not exist, so that "no such domain" cannot be forged either.

It does not provide:

  • Encryption. Queries and answers remain readable by anyone on the path. Privacy is the job of DNS over TLS or DNS over HTTPS, which protect the hop between client and resolver and complement DNSSEC rather than replace it.
  • Protection against a compromised DNS account. If an attacker can edit your zone, the provider will happily sign the attacker's records.
  • Protection of the web session. That is TLS. DNSSEC makes sure you reach the right address; the certificate proves the server is who it claims to be.
  • Anything for users whose resolver does not validate. Many large public resolvers and ISPs validate; not all do.

How it works

DNSSEC adds a handful of record types:

Record Where Purpose
RRSIG next to every record set the signature over that set (for example over all A records of www)
DNSKEY zone apex the zone's public keys
DS in the parent zone a hash of the child's key; the link in the chain
NSEC / NSEC3 throughout the zone proves which names and types do not exist
CDS / CDNSKEY zone apex lets the child signal DS changes to the parent automatically

Most zones use two keys. The zone-signing key (ZSK) signs the records. The key-signing key (KSK) signs only the DNSKEY set, and it is the KSK whose hash is published as the DS record in the parent. This split lets the ZSK be rotated often without involving the parent. Some providers use a single combined key (CSK) instead; the principle is the same.

The chain of trust

A validating resolver trusts exactly one thing out of the box: the public key of the root zone, signed since 2010. Everything else is derived:

root DNSKEY  (trust anchor, built into the resolver)
   └─ signs  DS for "com"          → matches com's DNSKEY
         └─ signs  DS for "example.com"   → matches example.com's DNSKEY
               └─ signs  www.example.com A 192.0.2.10

At each level the parent vouches for the child's key by publishing and signing a DS record. If every link verifies, the answer is secure and the resolver sets the ad (authenticated data) flag. If a zone has no DS in its parent, it is simply insecure: treated as ordinary unsigned DNS, no harm done. But if a DS exists and the signatures do not verify (wrong key, expired signature, missing RRSIG), the result is bogus, and the resolver returns SERVFAIL. For users behind validating resolvers the domain stops existing.

That last case is the entire operational risk of DNSSEC, and it explains the rules that follow.

One detail worth knowing: signatures expire. Each RRSIG has an inception and an expiration time. The signer must re-sign regularly. Managed DNS providers do this automatically; a self-hosted signer that stops running produces an outage a week or two later.

Checking DNSSEC with dig

Is there a DS record at the parent (i.e. is the domain meant to be signed)?

$ dig +short example.com DS
31589 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...

The fields are key tag, algorithm (13 = ECDSA P-256 with SHA-256, the usual modern choice), digest type (2 = SHA-256) and the digest.

Does the zone publish keys and signatures?

$ dig +dnssec +multi example.com DNSKEY
$ dig +dnssec www.example.com A
www.example.com.  3600 IN A      192.0.2.10
www.example.com.  3600 IN RRSIG  A 13 3 3600 20261004000000 20260920000000 31589 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr...

Does it validate? Ask a validating resolver and look at the flags:

$ dig www.example.com A @1.1.1.1 | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, ...

ad means the resolver validated the answer. To tell a DNSSEC failure from other failures, repeat a failing query with checking disabled:

$ dig www.example.com A @1.1.1.1          # status: SERVFAIL
$ dig www.example.com A @1.1.1.1 +cd      # status: NOERROR, answer present

SERVFAIL normally but an answer with +cd is the signature of a broken DNSSEC setup. delv www.example.com (shipped with BIND) performs validation locally and explains where the chain breaks.

How to enable DNSSEC

You need three parties to support it: the TLD (nearly all do), the DNS provider (signs the zone) and the registrar (passes the DS to the registry).

  1. Turn on signing at the DNS provider. It generates keys and starts publishing DNSKEY and RRSIG records. At this point nothing can break, because without a DS the zone is still "insecure".
  2. Verify the signed zone: dig +dnssec against the provider's nameservers should show RRSIGs for your records. Wait at least one TTL so that caches hold the signed data.
  3. Publish the DS record.
    • If registrar and DNS provider are the same company, this is usually one click, or automatic.
    • Otherwise copy the DS values (key tag, algorithm, digest type, digest) from the DNS provider into the registrar's DNSSEC form. Some registrars ask for the DNSKEY instead and compute the DS themselves. Copy carefully; one wrong character makes the domain bogus.
    • Some registries and registrars poll CDS/CDNSKEY records and create or update the DS on their own. If yours does, prefer that.
  4. Verify the chain with the commands above and an external validator, from more than one resolver.
  5. Monitor. Signature expiry and DS mismatches do not announce themselves until they fail.

The dangerous moments

  • Changing DNS provider or nameservers. The DS in the parent points at the old provider's key. Switch nameservers without handling it and the domain becomes bogus. Either remove the DS, wait for its TTL (often a day) to expire, move, then re-enable; or do a coordinated multi-signer migration. The full sequence is in changing nameservers without downtime.
  • Turning DNSSEC off. The order is the reverse of enabling: remove the DS first, wait out its TTL, and only then stop signing. Disabling signing while the DS is still published is the classic self-inflicted outage.
  • Transferring the domain to another registrar when the old registrar also hosts the DNS. See how to transfer a domain name.
  • Key rollovers on self-hosted signers. A KSK rollover involves the parent and must follow the publish–wait–switch–wait–remove pattern. With a managed provider this is their job.

Remember that lowering your own TTLs does not help with a broken chain: the DS record's TTL is set by the parent zone.

Common mistakes

  • Pasting the DS with a wrong algorithm or digest type number.
  • Leaving an old DS in place after moving DNS providers.
  • Disabling signing before removing the DS.
  • A self-hosted signer whose cron job died; everything works until the signatures expire.
  • Choosing NSEC without realising it allows the zone's names to be enumerated ("zone walking"). NSEC3, or the minimal-answer techniques that large providers use, make that harder.
  • Using outdated algorithms (RSA/SHA-1) when ECDSA P-256 gives smaller answers and is universally supported by current validators.
  • Assuming that because the site works for you, DNSSEC is fine. Your resolver may not validate.

Is it worth it?

For most domains on a managed DNS provider: yes. It is free, it is one or two clicks, and it removes a class of attack that is otherwise invisible to you. The cost is operational discipline at the few moments listed above. If your team changes DNS providers casually and nobody owns the registrar account, fix that first.

Check it with OrbitProbe

The OrbitProbe DNS lookup shows the records public resolvers return for your domain, with their TTLs. A signed domain that suddenly returns no records at all from validating resolvers, while your provider's panel looks normal, is the pattern to recognise: go straight to the +cd test above. The registry's view of the delegation, including whether it is marked as signed, appears in registration data as described in WHOIS vs RDAP.