What problem does DNSSEC solve?
DNS is unencrypted and unauthenticated by default. Anyone who compromises a DNS server between the browser and the destination (or poisons a resolver cache) can deliver arbitrary IP addresses for any domain — the browser ends up on a fake site, HTTPS certificate or not, and the attacker can intercept mail, steal credentials, or deliver malware. DNS cache poisoning has been documented since the early 2000s; the Kaminsky attack in 2008 brought the issue into the spotlight.
DNSSEC (DNS Security Extensions) solves this with cryptographic signatures: every DNS response is signed by the authoritative server, the resolver verifies the signature, and tampering in transit is detected immediately. A chain of trust from the root zone (.) down to your domain guarantees authenticity.
Key hierarchy
DNSSEC uses two key pairs:
- ZSK (Zone Signing Key) — signs the individual records (A, MX, TXT, ...). Rotated frequently (every few weeks to months), shorter (1024-2048 bit RSA or ECDSA P-256).
- KSK (Key Signing Key) — signs only the ZSK. Rotated rarely (1-2 years), longer (2048-4096 bit). The KSK signature is what anchors the chain of trust to the parent zone (e.g.
.com).
The split allows you to rotate the ZSK without having to update the DS record at the parent zone (registrar) every time — that would be extremely cumbersome.
The chain of trust
DNSSEC works top-down:
- The root zone has its KSK preinstalled in every resolver — the trust anchor.
- The root signs the DS record (hash of the KSK) of the TLD zones (.com, .de, .at, ...).
- The TLD signs the DS record of your domain.
- Your domain signs its own DNS records.
If the chain breaks anywhere (e.g. because your domain has DNSSEC enabled but the DS record is not registered with the registrar), DNSSEC is ineffective for your domain — and some resolvers will refuse the record entirely. This is called SERVFAIL and can take your whole domain offline in the worst case.
Enabling DNSSEC
Three steps, in this order:
- DNS host: Enable DNSSEC in the host's control panel. Cloudflare, Google Cloud DNS, AWS Route 53, and most major providers offer a one-click toggle. The host generates KSK + ZSK and signs your records.
- DS record at the registrar: The host shows you a DS record (digestType, keyTag, algorithm, digest). You enter this at your domain registrar (e.g. NIC.AT, GoDaddy, Namecheap). This closes the chain of trust.
- Validate: Use dnsviz.net or dnssec-debugger.verisignlabs.com — these tools display the full chain of trust graphically and reveal any gaps.
Common mistakes
- DS record not entered at the registrar: Domain becomes suddenly unreachable for DNSSEC-validating resolvers — looks like a total outage to users.
- Forgotten zone or key rotation: Expired signatures cause SERVFAIL. Automated rotation is mandatory — enabled by default at Cloudflare/Route 53.
- Host migration without rollover: When switching DNS hosts, the KSK must be transferred or a key rollover performed — otherwise the chain of trust is broken.
- Weak algorithms: RSA-SHA1 has been deprecated as insecure. Recommended: RSA-SHA256 (algorithm 8) or ECDSA-P256 (algorithm 13).
DNSSEC and DANE
An important DNSSEC application is DANE (DNS-based Authentication of Named Entities): it lets you specify in DNS itself which TLS certificates are valid for your domain — independent of the CA chain of trust. This turns DNSSEC into a complete trust foundation. Today it's used primarily for mail servers (Postfix, Exim); browser support for DANE-via-HTTPS remains limited.