Why DNSSEC is Essential for Domain Security

DNS was designed in the 1980s for a cooperative network, and it trusts answers by default. A resolver that receives a plausible reply to its question will usually accept it, cache it and hand it to every user who asks next. That openness is exactly what attackers exploit. DNSSEC (Domain Name System Security Extensions) fixes the core weakness by letting resolvers verify that an answer genuinely came from the zone owner and was not modified on the way. This article explains the problem DNSSEC solves, how its chain of trust works, and how to enable it without taking your domain offline.

If you are new to resolution itself, start with our guide on how DNS works; record types like A, MX and TXT are covered in understanding DNS records.

The problem: DNS answers can be forged

A classic DNS query is a small UDP packet. The resolver matches the reply using a few fields, such as the query ID and source port. If an attacker can guess or race those values, or sits on the network path, they can inject a fake answer. The best-known example is the cache poisoning technique publicised by Dan Kaminsky in 2008, which showed that an off-path attacker could poison a resolver’s cache for an entire domain within seconds under the right conditions.

Source port randomisation made such attacks much harder, but not impossible. Other threats remain:

• On-path manipulation on compromised routers, hostile Wi-Fi networks or rogue infrastructure.
• Resolver compromise, where a poisoned cache sends many users to a fake site at once.
• Redirection of mail by forging MX records, allowing interception of email that does not enforce encryption properly.

Encryption such as DNS over HTTPS protects the link between you and your resolver, but it does not prove that the resolver’s answer is authentic. DNSSEC does.

What DNSSEC does and does not do

DNSSEC provides origin authentication and data integrity. A validating resolver can confirm that a record set was signed by the key belonging to the zone, and that it has not changed since. It also offers authenticated denial of existence, so an attacker cannot fake a "this name does not exist" response.

What it does not do is equally important:

• It does not encrypt DNS queries or answers. Anyone on the path can still read them.
• It does not protect against a hijacked registrar account. If someone changes your name servers and DS record at the registrar, the forged data will validate.
• It does not secure the website itself; you still need HTTPS and a valid certificate.

The new record types

How the chain of trust works

A validating resolver only needs one key it trusts in advance: the root zone’s key-signing key, configured as a trust anchor. From there it follows a chain:

1. The root’s DNSKEY set is verified with the trust anchor.
2. The root zone contains a signed DS record for com. The resolver checks the RRSIG on that DS with the root’s key.
3. The resolver fetches the DNSKEY set of com and confirms that one key matches the DS hash.
4. The same pattern repeats: com publishes a signed DS for example.com, which must match a DNSKEY in your zone.
5. Finally, your DNSKEY verifies the RRSIG on the answer the user asked for, such as the A record of www.example.com.

If every link checks out, the resolver sets the AD (authenticated data) flag. If any link fails, a validating resolver refuses the answer and returns SERVFAIL. If the parent has no DS record for a zone, that zone is simply treated as unsigned (insecure) and resolved normally.

KSK and ZSK

Most zones use two roles of keys:

• The Key Signing Key (KSK) signs only the DNSKEY set. Its hash is what you publish as the DS record at the parent, so changing it requires a registrar update.
• The Zone Signing Key (ZSK) signs all other records. It can be rolled frequently and entirely within your zone, without touching the parent.

In DNSKEY records, the KSK typically shows flags 257 and the ZSK 256. Some providers use a single Combined Signing Key; that works too, but every key rollover then needs a DS update.

Algorithm 13 and why it is the common choice

Every key and signature names an algorithm number. Algorithm 8 (RSA/SHA-256) was the long-standing default and is still widely supported. Algorithm 13 (ECDSA Curve P-256 with SHA-256) is now recommended by current best-practice guidance and used by default at many large DNS providers, for several reasons:

• Much smaller keys and signatures than RSA at comparable strength, which keeps DNS responses small.
• Smaller responses reduce the chance of UDP fragmentation and fallback to TCP.
• Broad validator support across modern resolvers.

Algorithm 15 (Ed25519) is also recommended, but some older validators and registries support it less consistently. The DS digest type is a separate number: digest type 2 (SHA-256) is the usual choice.

Checking DNSSEC with dig

Ask for DNSSEC data with +dnssec and look for RRSIG records and the ad flag (output shortened):

$ dig +dnssec example.com A

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
example.com.  300  IN  A      93.184.215.14
example.com.  300  IN  RRSIG  A 13 2 300 20261021000000 20261007000000 12345 example.com. (signature)

In the RRSIG, 13 is the algorithm, 12345 is the key tag, and the two timestamps are the signature expiry and inception. To compare your keys with the parent:

$ dig example.com DNSKEY +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...
256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz...

$ dig example.com DS +short
12345 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...

The DS line reads: key tag, algorithm, digest type, digest. The key tag and algorithm must correspond to the KSK (flag 257) in your DNSKEY set. Online analysers such as DNSViz draw the full chain and highlight broken links.

Common failures and SERVFAIL

The tricky part is that only validating resolvers fail. Users of a non-validating resolver see your site normally, so a DNSSEC break can look like a mysterious partial outage. Running dig +cd (checking disabled) against a validating resolver helps: if the query works with +cd and fails without it, DNSSEC is the culprit.

How to enable DNSSEC safely

1. Confirm support. Your TLD, registrar and DNS provider must all support DNSSEC. Most major TLDs are signed.
2. Turn on signing at the DNS provider. Choose algorithm 13 if offered and let the provider manage ZSK rollovers automatically.
3. Publish the DS record at the registrar. Copy the key tag, algorithm, digest type and digest exactly. Some registrars and providers automate this using CDS/CDNSKEY records.
4. Verify. Check for the ad flag through a validating resolver and review the chain in an analyser.
5. Plan migrations. When changing DNS providers, either transfer keys properly or remove the DS, wait for the parent DS TTL to expire, migrate, and re-enable.

DNSSEC also depends on the registrar account staying healthy, because that is where the DS lives. Keep an eye on registrar, name server and expiry details with the TLDix WHOIS and RDAP lookup, and track renewals for your whole portfolio in the TLDix panel so a lapsed registration never breaks the chain.

Is DNSSEC worth it?

For domains that carry email, logins, payments or any brand trust, the answer is generally yes. With modern providers, signing is largely automatic, and algorithm 13 keeps the overhead small. The real operational risk sits in a few predictable moments, chiefly DS changes and provider migrations. Handle those carefully and DNSSEC quietly closes a gap that has existed in DNS since the beginning, while also enabling technologies such as DANE that build on signed DNS data.