DNSSEC: how to know DNS answers can be trusted.

The standard Domain Name System was designed in the 1980s without security in mind. When you type a domain into your browser, your computer asks a series of DNS resolvers "what IP address serves this domain?" Each resolver caches the answer for future speed — but without any way to verify the response came from the legitimate source.

This creates the DNS cache poisoning attack: a malicious actor injects a fake DNS answer into a resolver's cache. Every user that resolver serves then gets directed to the attacker's server instead of the real one. Kaminsky's 2008 discovery proved this attack was practical at scale, accelerating DNSSEC deployment.

DNSSEC does not encrypt DNS queries or responses — that's the job of DNS over HTTPS (DoH) or DNS over TLS (DoT). Instead, DNSSEC signs the DNS data itself so any resolver can verify authenticity without trusting the network path.

DNSSEC creates a hierarchical chain of trust that starts at the DNS root zone and extends down to every signed domain.

Zone Signing Key (ZSK): Each DNS zone generates a ZSK to sign individual DNS records. The ZSK is used frequently and is rotated regularly (typically monthly or quarterly).

Key Signing Key (KSK): A separate, longer-lived KSK signs only the ZSK. Because the KSK changes less often, it can be protected with stricter access controls — for TLD operators, this typically means an HSM (Hardware Security Module).

Delegation Signer (DS) record: The parent zone publishes a hash of the child zone's KSK as a DS record. This is how trust chains across zone boundaries — the parent's signature on the DS record vouches for the child's KSK.

RRSIG records: Every signed DNS record set is accompanied by an RRSIG (Resource Record SIGnature) that resolvers use to verify authenticity.

When a DNSSEC-validating resolver asks for a record, it follows the chain of signatures from the root through each DNS zone until it reaches the answer, verifying each signature along the way. If anything doesn't match, the resolver returns a SERVFAIL rather than an unauthenticated answer.

ICANN mandates DNSSEC signing for all new gTLD registries. Before delegation, applicants must demonstrate DNSSEC capability as part of the RSP (Registry Service Provider) technical evaluation.

For TLD operators, DNSSEC management involves:

• Key ceremonies: Formal, audited events where KSKs are generated or rolled over, typically requiring multiple witnesses and a Hardware Security Module (HSM)
• HSM management: KSKs for TLD operators should be stored in FIPS 140-2 validated HSMs to prevent key extraction
• Key rollover: ZSKs are rotated regularly; KSK rollover follows ICANN's prescribed schedule
• DS record submission: After each KSK change, the new DS record must be submitted to IANA for publication in the root zone
• Monitoring: Signature expiration must be monitored 24/7 — an expired signature breaks DNSSEC validation for end users

ADG manages this entire lifecycle for TLD operators: key ceremonies, HSM custody, automated signing, signature refresh, and emergency key rollover — all included in our RSP service.

These two technologies solve different problems and are complementary:

A TLD can have DNSSEC enabled and DNS-over-HTTPS disabled (or vice versa). For maximum security, both are recommended.