DNS cache poisoning attacks are real and DNSSEC exists to stop them. Here's what DNSSEC actually does, how to verify it's working, and why your hosting provider's implementation matters.
DNS is the phone book of the internet. When you type yoursite.com, your computer asks a DNS resolver to translate that name into an IP address. The protocol that underlies this lookup was designed in 1983 and published in 1987. It has essentially no authentication built in.
DNSSEC — the DNS Security Extensions — is the retrofit. It adds cryptographic signatures to DNS records so that a resolver can verify the answers it receives haven't been tampered with. This guide explains what that means in practice, how to check whether a domain has DNSSEC enabled, and why your hosting provider's implementation matters.
A DNS cache poisoning attack (also called DNS spoofing) works like this: an attacker manages to inject a false DNS record into a resolver's cache. Instead of returning the real IP for yourbank.com, the poisoned resolver returns an IP that the attacker controls. The user types the correct URL, makes a genuine request, and arrives at a fake site — with no indication anything is wrong in the browser.
This isn't theoretical. The Kaminsky attack in 2008 demonstrated a practical method for poisoning DNS caches in resolvers that had no DNSSEC validation. It triggered an emergency patch to virtually every DNS resolver in production.
DNSSEC prevents this by ensuring that each DNS record comes with a cryptographic signature. A validating resolver checks the signature against a chain of trust going back to the root DNS zone. A poisoned record fails validation because the attacker can't produce a valid signature for the real domain's zone.
DNSSEC operates in a hierarchy that mirrors DNS itself. The root zone (.) is signed by ICANN. Each TLD zone (.uk, .com, .org) is signed by its registry. Each domain zone is signed by the zone operator — your DNS provider or hosting company.
The chain works like this:
For this to work for your domain, two things must be true: your DNS zone must be signed (your DNS provider signs the records), and a DS record must be published in the TLD registry (this is done by your domain registrar, which communicates the DS record to Nominet for .uk domains, or Verisign for .com).
The quickest check is with dig:
dig yourdomain.com +dnssec
If DNSSEC is enabled, you'll see RRSIG records alongside the regular A or AAAA records. You'll also see AD (Authentic Data) flag in the response header if your resolver is doing DNSSEC validation.
To check whether the DS record exists in the parent zone:
dig yourdomain.co.uk DS
An empty answer means no DS record — DNSSEC validation cannot complete even if the zone is signed.
For a more complete view, the DNSSEC Analyzer from Verisign Labs walks through the entire chain of trust for any domain and shows exactly where it breaks if something is misconfigured.
Understanding the record types helps when debugging:
DNSKEY — the public key for the zone. A zone typically has two: a Zone Signing Key (ZSK) that signs the regular records, and a Key Signing Key (KSK) that signs the ZSK.
RRSIG — a signature over a set of DNS records. Each record set gets its own RRSIG, signed by the ZSK.
DS — the hash of the KSK published in the parent zone. This is what links the zone into the chain of trust.
NSEC / NSEC3 — records that prove the non-existence of a name. Without these, an attacker could strip records from a response and make legitimate records appear not to exist.
DNSSEC has a reputation for being complex to operate correctly. The reputation is deserved. The failure modes are:
Expired signatures — RRSIG records have validity periods. If the automatic signing process fails and signatures expire, DNSSEC-validating resolvers will refuse to resolve your domain entirely. This has taken down well-known services.
Key rollover failures — Signing keys need periodic rotation. The rollover process must be coordinated between the zone itself and the DS record in the parent zone. Doing it incorrectly breaks the chain of trust.
Registry lag — DS records live at the registrar/registry level. If a host rotates keys but the registrar doesn't update the DS record in time, validation breaks.
At FXRM, we run PowerDNS for DNS hosting, which handles DNSSEC signing automatically including key rotation. We monitor signing status and work with registrars to ensure DS records are kept current. It's not the kind of thing you want to manage manually.
If you want your DNS infrastructure to include DNSSEC on every zone by default, see our hosting plans → or talk to us directly →.
Founded by Jon Morby, whose team has been running UK servers since 1992. Hosting built by engineers who care about deliverability and uptime.
Get in touch →Shared hosting has historically meant PHP. Enhance changes that with native Node.js app support. Here's what actually works, what has limits, and when Node workloads need a VPS.
Most VPS hosts run OpenVZ or Xen. FXRM runs KVM on Proxmox. The difference is more than a product spec — it changes what isolation and resource guarantees actually mean.
A single SMTP server is a single point of failure. This is the actual HAProxy configuration we use for mail relay failover, including health checks, stick tables, and SMTP protocol handling.