What is DNSSEC

DNSSEC adds cryptographic signatures to DNS records. This prevents DNS Cache Poisoning attacks — an attacker cannot replace your domain's A record with their own IP.

Technically, the chain of trust is built on three record types: DNSKEY publishes the zone's public keys, RRSIG is the signature of a specific record set made with that key, and DS at the parent zone (for example, at the .com registry) confirms that this particular DNSKEY belongs to your domain. A resolver checks the chain from the root zone down and either marks the answer as Authenticated Data (AD) or discards it as Bogus.

💡 DNSSEC is especially important for financial and medical sites, where DNS spoofing can lead to phishing.

Enabling DNSSEC in cPanel/WHM

WHM → DNS Functions → DNSSEC Manager → select the domain → Create Keys

After the keys are created, cPanel will show a DS record (Delegation Signer) — it needs to be added at your registrar.

Adding a DS record at your registrar

Most registrars have a DNSSEC or DS Records section:

Key Tag
Algorithm (usually 13 — ECDSAP256SHA256)
Digest Type (usually 2 — SHA-256)
Digest (hash of the public key)

Algorithm 13 (ECDSAP256SHA256) is the current standard for new zones: shorter keys, faster signing. Algorithm 8 (RSASHA256) also shows up — it's older, but fully supported by every modern resolver, so switching a working zone from 8 to 13 isn't necessary if it's already signed and functioning.

Checking DNSSEC

# Check via dig
dig yourdomain.com +dnssec +short

# Online check
# dnssec-analyzer.verisignlabs.com

Status	Meaning
✅ Secure	DNSSEC is working correctly
⚠️ Insecure	DNSSEC is not configured
❌ Bogus	Signature error — configuration problem

An Insecure status for a resolver doesn't mean an error — that's how the vast majority of domains on the internet look, since they simply aren't signed. But going from Secure to Bogus is already an incident: resolvers with validation turned on (Unbound or BIND with dnssec-validation yes, for instance) will refuse to resolve the domain at all in that case, rather than just trusting the answer less.

⚠️ After enabling DNSSEC, be careful when changing NS servers — you must remove the DS records at the registrar first, or the domain will stop resolving.

Common DNSSEC Errors

Symptom	Cause	Fix
dig +dnssec returns SERVFAIL right after enabling	The DS record hasn't been added at the registrar yet, or it has a typo in the Digest	Compare the Key Tag and Digest in WHM against what's entered at the registrar, character by character
Bogus status in dnssec-analyzer	The zone's signature doesn't match the published DS record — for example, the keys were regenerated but the DS wasn't updated	Update the DS record at the registrar right after rotating the DNSSEC keys
The domain stops resolving entirely after enabling	The DS record was added before the zone was actually signed, or the other way around	Temporarily remove the DS at the registrar, verify the zone signature, then add the DS again
no valid RRSIG in resolver logs	The signature has expired (RRSIG expiration) and automatic re-signing didn't run	Check that the zone-signing daemon is running and executing on schedule

Most of these situations come down to the same thing: the DS record at the registrar and the zone signature at the DNS provider are two independent systems that have to be changed in sync, by hand. Neither one automatically knows the state of the other, so any asymmetric edit — updating one and forgetting the other — temporarily breaks resolution for anyone checking DNSSEC.

When Not to Enable DNSSEC

The zone changes NS delegation often during hosting migrations — the risk of DS getting out of sync outweighs the benefit; stabilize delegation first
The domain's registrar doesn't support adding DS records — true for some ccTLDs, in which case enabling it in the hosting panel is pointless: the domain stays unsigned at the parent zone level regardless
There's no process for key rotation and RRSIG monitoring — a forgotten expired signature will break resolution for the domain entirely, not just weaken its protection
DNS is set up with fast automatic IP failover — frequent configuration changes make DNSSEC harder to debug in that setup, see DNS failover

Verifying After Key Rotation

# Check the published DS record at the parent zone's registry
dig yourdomain.com DS +short

# Check the signature of a specific record
dig yourdomain.com A +dnssec

# Confirm the resolver set the AD (Authenticated Data) flag
dig yourdomain.com A +dnssec | grep -i flags

The AD flag only shows up in the answer if the resolver you're querying is itself configured to validate DNSSEC — public resolvers like 8.8.8.8 and 1.1.1.1 do this by default, while some providers' default resolver may not set AD even when the domain's signature chain is fully correct.