Blog

DNS & Domains articles

DNSSEC Explained for Website Owners

What DNSSEC protects against, how the chain of trust works, how to enable it with your registrar and DNS host, and the mistakes that take domains offline.

5 min read DNS & Domains

DNS was designed in an era when nobody expected anyone to lie. When a resolver receives an answer, plain DNS gives it no way of checking that the answer really came from your domain's name servers and was not altered on the way. DNSSEC (DNS Security Extensions) fixes that by adding digital signatures to DNS records. This guide explains what it does in practical terms, what it does not do, and how to switch it on without causing an outage.

The problem DNSSEC solves

The main threat is cache poisoning: an attacker tricks a resolver into caching a forged answer, for example sending everyone who asks for your bank's domain to the attacker's server. Other risks include tampering by a compromised network device between the resolver and your name servers. In each case the victim's computer receives a perfectly ordinary-looking DNS answer that happens to be false.

With DNSSEC, a validating resolver checks a cryptographic signature on every answer. A forged or altered answer fails the check, and the resolver refuses to use it.

What DNSSEC does not do

It is worth being clear about the limits, because DNSSEC is often misunderstood:

  • It does not encrypt anything. DNS queries and answers remain readable. Privacy is the job of encrypted transports such as DNS over HTTPS or DNS over TLS.
  • It does not protect your registrar or DNS account. If someone logs into your DNS provider and changes a record, DNSSEC will happily sign the attacker's record. Strong passwords and two-factor authentication matter more for most businesses.
  • It does not replace HTTPS. Certificates still prove the identity of the website itself.
  • It only helps when resolvers validate. Major public resolvers, including Google Public DNS, Cloudflare's 1.1.1.1 and Quad9, do validate, as do many ISP resolvers.

How DNSSEC works: the chain of trust

DNSSEC introduces a few new record types:

RecordWhere it livesPurpose
RRSIGYour zoneA signature over a set of records, such as all the A records for www
DNSKEYYour zoneThe public keys used to check those signatures
DSThe parent zone (e.g. .com)A fingerprint of your key, vouching for it
NSEC / NSEC3Your zoneSigned proof that a name or record type does not exist

A resolver trusts the root zone's key, which is built into its configuration. The root zone contains a signed DS record for .com; .com's keys sign a DS record for example.com; and example.com's keys sign its own records. Each link vouches for the next, forming a chain from the root to your record. Break any link and validation fails.

Many zones use two keys: a key signing key (KSK), whose fingerprint is the DS record at the parent, and a zone signing key (ZSK), which signs the everyday records. Some providers use a single combined key. Either way, the DS record at the registry is the anchor that connects your zone to the chain.

How to enable DNSSEC

For most website owners, enabling DNSSEC is a two-part job split between your DNS host and your registrar.

  1. Turn on signing at your DNS host. Most managed DNS providers offer a DNSSEC toggle. They generate keys, sign the zone and re-sign automatically whenever you edit a record. They will then show you the DS record details: a key tag, algorithm number, digest type and digest.
  2. Add the DS record at your registrar. In the registrar's domain settings, find the DNSSEC section and enter those DS details exactly. If your DNS host and registrar are the same company, this step is often automatic. Some registries and DNS hosts also support automatic DS publication using CDS records.
  3. Wait and verify. Once the registry publishes the DS record, validating resolvers start enforcing signatures.

Modern setups typically use algorithm 13 (ECDSA P-256 with SHA-256), which produces small signatures and is widely supported. Your provider will choose for you.

How to check DNSSEC is working

From the command line, ask a validating resolver and look for the ad (authenticated data) flag in the header:

dig example.com A +dnssec @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2 ...

For many extensions, a WHOIS lookup also shows whether the delegation is signed. You can confirm the DS record is published with dig example.com DS +short, and see your keys with dig example.com DNSKEY +short. A failing domain typically returns SERVFAIL from validating resolvers but works from non-validating ones; adding +cd (checking disabled) to a dig query will return an answer even when validation fails, which is a quick way to confirm DNSSEC is the cause. Our DNS lookup tool is handy for checking individual records from a browser.

The mistakes that take domains offline

DNSSEC failures are severe: validating resolvers do not show a warning, they simply refuse to resolve the domain. The usual causes are:

  • Changing DNS provider with the old DS record still at the registry. The new provider's keys do not match, so every answer fails. Remove the DS record and wait for its TTL to expire before moving, then re-enable DNSSEC at the new provider. Only change the name servers once dig example.com DS +short returns nothing from the public resolvers you test.
  • Turning off signing at the DNS host while the DS record remains at the registrar. Always remove the DS first.
  • A typo in the DS record entered manually at the registrar.
  • Expired signatures on self-managed name servers where automatic re-signing stopped running. Signatures carry expiry dates and must be refreshed.

Should you enable DNSSEC?

If your DNS host and registrar both support it with automatic key management, the ongoing effort is low and it removes a real class of attack, so it is a sensible default, particularly for banks, e-commerce, government and anything handling sensitive logins. It also underpins newer standards such as DANE for email. If you run your own name servers, or move DNS providers often, weigh the extra operational care required. In every case, secure your registrar and DNS accounts first.

Key takeaways

  • DNSSEC signs DNS records so validating resolvers can detect forged or altered answers.
  • It does not encrypt DNS or protect a compromised DNS account.
  • Enabling it means signing at your DNS host and publishing a DS record at your registrar.
  • Always remove the DS record before switching DNS providers or turning signing off.

Need help with this?

Netifi helps businesses around the world with DNS & Domains. Tell us what you are working on.