Domain insights

DNSSEC explained: what signed DNS protects and how to verify it

DNSSEC lets validating resolvers detect forged DNS data. Learn what it does, what HTTPS still does, how the chain of trust works, and how to avoid a broken delegation.

DNS Security
DNSSEC explained: what signed DNS protects and how to verify it

DNSSEC adds cryptographic proof to DNS data so a validating resolver can reject an altered or forged answer. It protects the path from the signed zone to the resolver, but it does not encrypt DNS traffic, secure a web session or replace HTTPS. Enable it only when your DNS provider can sign the zone and your registrar or registry can publish the matching DS record.

DNSSEC in one minute

QuestionPractical answer
What does it stop?Accepted forged or modified DNS answers at validating resolvers
Does it encrypt DNS?No. Encryption requires a separate transport such as DoH or DoT
Does it replace HTTPS?No. HTTPS authenticates the website and encrypts the browser session
What links the parent and child?A DS record at the parent points to a key in the signed child zone
What is the main risk?A stale or incorrect DS can make every validating resolver return failure
DNSSEC illustration comparing forged DNS protection with risks DNSSEC does not cover
DNSSEC validates DNS data. HTTPS, anti-phishing controls and endpoint security still solve different problems.

The problem DNSSEC solves

Classic DNS answers are not inherently signed. An attacker who succeeds in feeding a resolver a forged answer may redirect a user to the wrong address. DNSSEC lets the resolver verify that the data was signed by the expected zone and has not changed. HTTPS remains essential because it authenticates the web endpoint and encrypts application traffic even after DNS resolution.

The chain of trust: RRSIG, DNSKEY and DS

  • RRSIG: A signature generated over a DNS record set. The resolver checks it with a public key from DNSKEY.
  • DNSKEY: A public key published inside the signed zone. Its matching private key remains with the signing service.
  • DS: A digest published in the parent zone that identifies the trusted child key. The registrar normally sends this data to the registry.
  • Validation: The resolver follows trust from the DNS root to the TLD and then to the domain. A missing link makes the zone insecure; a contradictory signed link can make it bogus.
Cartoon diagram of the DNSSEC chain of trust from the DNS root and registry DS record to a signed domain
The parent DS record links the trusted hierarchy to the signing key published by the domain.

KSK and ZSK are roles, not a requirement for two visible keys

Many operators separate a key-signing key from a zone-signing key to simplify rollover and limit exposure. Other services use a combined signing key or automate key management differently. DNSSEC requires valid signatures and a correct chain of trust; it does not require every zone owner to manually operate two keys.

How to verify a signed domain

  1. Request signatures: Run dig +dnssec example.hn A. A signed answer should include an RRSIG for the returned record set.
  2. Inspect zone keys: Run dig +dnssec example.hn DNSKEY and record the key tag used by the signatures.
  3. Inspect the parent link: Run dig +dnssec hn DS for a TLD or use a trace to inspect the DS that delegates trust to the domain.
  4. Look for authenticated data: A validating resolver may return the ad flag when it successfully validates the answer. The flag is meaningful only when you trust that resolver to validate.
  5. Treat SERVFAIL as a warning: If ordinary answers work through a nonvalidating path but validating resolvers return SERVFAIL, investigate signatures, DS data, time and rollover state.

Safe enablement sequence

  1. Confirm support: Verify that the DNS host signs the zone and the registrar supports DS submission for the exact TLD.
  2. Sign first: Enable signing at the authoritative DNS provider and confirm DNSKEY and RRSIG are publicly visible.
  3. Publish the DS: Copy algorithm, digest type, digest and key tag exactly. Never recreate the values by hand unless you operate the signer.
  4. Validate externally: Test through more than one validating resolver and keep monitoring through any key rollover.

Troubleshooting checklist

  • Compare DS and DNSKEY: Confirm the parent DS matches a current DNSKEY and algorithm supported by the signer.
  • Check time and expiration: RRSIG records have inception and expiration times. Incorrect signer time or an expired signature breaks validation.
  • Check all authoritative servers: Every server must serve consistent signed data. A lagging server can create intermittent failures.
  • Review rollover state: Keep old and new material available for the required overlap before removing a key or DS.
  • Escalate with evidence: Send the provider the domain, failing record type, resolver, UTC time and complete dig output.

DNSSEC and country domains

DNSSEC availability is specific to the registry, registrar and DNS host combination. A ccTLD can support DNSSEC at the registry while a particular registrar workflow does not expose DS management, or a hosted DNS product may automate it. Check the product page and ask for confirmation before treating support as included.

Frequently asked questions

Does DNSSEC prevent someone from reading DNS queries?

No. DNSSEC authenticates DNS data but does not encrypt the query or response. Encrypted DNS transports such as DoH or DoT address transport privacy.

Why can DNSSEC make a domain appear offline?

Validating resolvers reject a zone when a published DS no longer matches the available signed keys or signatures are invalid. This often appears as SERVFAIL even though an authoritative server still answers.

Do I need separate KSK and ZSK keys?

Not necessarily. They are common operational roles, but managed signers may use a combined key or another automated model. Follow the signer design and focus on a valid DS and current signatures.

Should I remove DNSSEC before changing nameservers?

Do not improvise. Follow the documented rollover or migration process for both providers and the registrar. An old DS with new unsigned or differently signed nameservers can break validation.