(267) 200-2872 Free Security Scan

← All articles

Why Do So Many Domains and Websites Not Use DNSSEC?

Run your domain through almost any security scanner and you'll probably see a warning: DNSSEC not enabled. It looks like an easy fix and an obvious gap. Yet most domains on the internet, including plenty run by large, security-conscious companies, don't use DNSSEC.

That isn't an oversight. For most businesses, DNSSEC adds more risk than it removes. The attack it stops is narrow and already blunted by HTTPS, while the way it fails can take your whole domain offline. This article explains what DNSSEC does, what it protects, and why skipping it is a reasonable decision.

What DNSSEC actually does

DNS (the Domain Name System) is the internet's phone book: it turns a name like example.com into the address of a server. Plain DNS has no built-in proof that an answer is genuine. A resolver, the server that looks names up on behalf of your computer, generally trusts whatever answer arrives first.

DNSSEC (DNS Security Extensions) adds digital signatures to DNS records. Your DNS host signs your records with a private key, and a fingerprint of that key, the DS record, is published through your registrar in the parent zone (for example .com). A resolver that checks signatures can then prove an answer really came from you and wasn't altered on the way.

Two things DNSSEC does not do: it doesn't encrypt anything, and it only helps when the visitor's resolver actually checks the signatures.

The attack it stops, and how big it really is

DNSSEC exists to stop DNS spoofing or cache poisoning: an attacker tricks a resolver into storing a fake answer, so people using that resolver are sent to the attacker's server instead of yours.

That's a real attack, but its reach is limited:

  • It hits one resolver at a time. Poisoning an ISP's or an office's resolver affects the people using that resolver, not the whole internet.
  • It's temporary. The fake answer lasts until it expires from the cache, typically minutes to hours.
  • It's harder than it used to be. Since the well-known Kaminsky attack in 2008, resolvers randomize the network details of each lookup, which makes guessing a fake answer into place far more difficult.

In other words, a successful poisoning is a one-off event with a limited blast radius. The question is what the attacker can do with it.

Why HTTPS already covers your website

Suppose an attacker does poison a resolver and sends some of your visitors to their own server. Those visitors' browsers still expect a valid SSL/TLS certificate for your domain, and the attacker doesn't have one. The browser shows a full-page security warning instead of your site.

Two settings turn that warning into a hard stop:

  • HSTS (HTTP Strict Transport Security) tells browsers to only ever connect to your site over HTTPS and not to let users click past certificate errors.
  • CAA records list which certificate authorities may issue certificates for your domain, which narrows who an attacker could try to fool into issuing one.

Certificate authorities have also tightened up. They now check domain control from several network locations at once, so a poisoned resolver in one place isn't enough to obtain a certificate. Every certificate issued is also published in public Certificate Transparency logs, so a rogue certificate for your domain can be spotted.

So for a website with a properly configured certificate, DNS poisoning mostly produces a scary error page for some visitors, for a while. It's an annoyance, not a breach.

The real problem: DNSSEC fails closed

Here's the trade-off that scanners don't mention. When DNSSEC is misconfigured, validating resolvers don't fall back to plain DNS. They treat your domain as broken and return no answer at all. Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 and many ISPs validate, so a DNSSEC mistake makes your website, email and everything else on the domain disappear for a large share of the internet.

And mistakes are easy, because DNSSEC usually involves two separate companies that must stay in sync:

  • your DNS host, which holds the signing keys and signs your records, and
  • your registrar, which publishes the matching DS record in the parent zone.

If those two ever disagree, your domain goes dark. Common ways it happens:

  • Moving to a new DNS provider without first removing the old DS record. The new provider's signatures don't match, and validation fails.
  • Key changes (key rollovers) done in the wrong order or too fast, before old records have expired from caches.
  • Expired signatures, if signing is automated and the automation quietly stops.
  • Transferring the domain to another registrar, where the DS record can be lost or carried over incorrectly.

This isn't theoretical. In September 2021, Slack tried to enable DNSSEC on slack.com; a problem during the rollout left the site unreachable for a portion of its users for up to about a day, and the team ultimately rolled DNSSEC back. If a company with Slack's engineering staff can trip over it, a small business with one part-time IT person certainly can.

Compare the two failure modes. Without DNSSEC, the worst realistic case is a temporary poisoning that HTTPS mostly neutralizes. With DNSSEC, the worst realistic case is your own configuration taking the entire domain offline for everyone using a validating resolver, and fixing it may need two companies' support desks plus hours of waiting for caches to expire.

"Just use one provider for both"

The easy way to avoid the two-company problem is a provider that is both your registrar and your DNS host. Then a single company holds the keys and the DS record, and DNSSEC really can be a one-click setting.

The catch is that only a handful of providers do both, and the big registrars that bundle DNS, GoDaddy being the familiar example, aren't where you'd choose to host DNS on its merits. In our experience, registrar-bundled DNS tends to be basic: fewer features, slower propagation of changes across their nameservers, and less control than a dedicated DNS provider. Cloudflare is the notable exception with fast DNS, but its registrar only works for domains that also use Cloudflare's DNS, so you're locked into one company for both jobs.

So the choice usually comes down to: pick your DNS host for DNSSEC convenience, or pick it for quality and accept the operational complexity of DNSSEC across two providers. Most businesses sensibly choose quality and skip DNSSEC.

What about email?

Email is where the argument for DNSSEC is strongest. Mail servers find each other through DNS (MX records), and server-to-server encryption is often opportunistic: if an attacker can fake the DNS answer, they may be able to redirect or read mail in transit. DANE, a standard that pins mail servers' certificates in DNS, fixes this, but it requires DNSSEC.

Two points take most of the weight out of that argument:

  • MTA-STS gives similar protection without DNSSEC. It publishes a policy over HTTPS telling other mail servers to require encrypted, certificate-checked delivery to your domain. Gmail and Microsoft 365 both honor it.
  • Email is insecure by design anyway. Messages are routinely stored unencrypted on servers along the way, sender addresses can be forged, and phishing works regardless of DNS. That's exactly why anything that really matters, such as banking, payroll and admin logins, relies on multi-factor authentication (MFA, a second step like an app code or security key) rather than trusting email alone.

Protecting the DNS lookup for email locks one door of a house with no walls. Your effort is better spent on SPF, DKIM, DMARC, MTA-STS and MFA everywhere.

When DNSSEC does make sense

DNSSEC isn't useless, and some organizations should run it:

  • When it's required, such as U.S. federal .gov domains or contracts that specify it.
  • High-value targets such as banks, registrars and large platforms, with staff dedicated to running DNS carefully.
  • When you need DANE, for example to interoperate with mail systems that rely on it.
  • When your registrar and DNS host are the same company and you're happy with that provider anyway.

If you do turn it on, a few habits prevent most outages:

  • Remove the DS record at the registrar, and wait for it to expire from caches, before moving to a new DNS provider.
  • Use automatic DS updates (the CDS/CDNSKEY records) if your registrar supports them, rather than copying keys by hand.
  • Monitor validation from outside, for example with DNSViz or a scheduled check like this:
# Is there a DS record in the parent zone?
dig +short DS example.com

# Does a validating resolver accept the answer? Look for "ad" in the flags.
dig +dnssec example.com @1.1.1.1

The bottom line

DNSSEC solves a narrow problem that HTTPS and certificate checks already largely contain, and it does so by adding a failure mode that can take your entire domain offline. Unless your registrar and DNS host are the same reliable company, or you have a specific requirement, leaving it off is a defensible, deliberate choice.

Spend the effort where attacks actually happen: valid certificates with HSTS, CAA records, SPF/DKIM/DMARC and MTA-STS for email, and MFA on every account that matters. So the next time someone gives you a hard time about not using DNSSEC, tell them to relax.