DNSKEY DNS Public Key Common
Publishes the public key used to verify DNSSEC signatures for a zone.
What it's for
A DNSKEY record publishes a public key that resolvers use to verify DNSSEC (DNS Security Extensions) signatures within a zone. DNSSEC exists to solve a real problem with plain DNS: nothing stops a malicious network position (a rogue resolver, a man-in-the-middle, cache poisoning) from returning forged DNS answers. DNSSEC adds cryptographic signing so a validating resolver can confirm the answer it received actually came from the zone's legitimate operator and wasn't tampered with in transit.
A zone typically publishes two DNSKEY records serving different roles: a Zone Signing Key (ZSK) that signs the zone's regular records, and a Key Signing Key (KSK) that signs the DNSKEY record set itself — splitting these lets the ZSK be rotated more frequently without disturbing the chain of trust anchored by the KSK.
Format & syntax
example.com. 3600 IN DNSKEY 257 3 8 AwEAAbc123...
- Flags —
256typically indicates a ZSK,257indicates a KSK (the extra bit signals "this is a secure entry point") - Protocol — always
3per spec (a fixed legacy value) - Algorithm — a number identifying the signing algorithm, e.g.
8for RSA/SHA-256,13for ECDSA P-256/SHA-256 - Public Key — the base64-encoded public key material itself
The corresponding private key never appears in DNS — it's held securely by whoever signs the zone (the DNS operator or their DNSSEC-enabled provider) and is used to generate RRSIG records over the zone's data.
How it's used in practice
- Validating resolvers checking authenticity — a DNSSEC-aware resolver (like most major public resolvers today) uses the zone's DNSKEY to verify the RRSIG signatures attached to answers, confirming the data hasn't been forged or tampered with.
- Chain of trust to the parent zone — the DNSKEY (specifically the KSK) is hashed and published as a DS record in the parent zone, linking trust from the root down through each delegation, so a resolver can validate an entire chain from the DNS root to your specific zone.
- Key rotation — DNSSEC-enabled zones periodically rotate their ZSK (and less frequently their KSK) as a security best practice; managed providers that support DNSSEC (Cloudflare, Route 53) typically automate this rotation.
- Enabling DNSSEC on a domain — turning on DNSSEC at your DNS provider generates DNSKEY records automatically; the manual step that's still often required is publishing the corresponding DS record at your registrar to complete the chain of trust.
Common mistakes & gotchas
- Enabling DNSSEC signing but forgetting the DS record at the registrar — this is the single most common DNSSEC misconfiguration. Without a matching DS record published at the parent/registry level, the chain of trust is broken and validating resolvers may treat your entire domain as unreachable ("SERVFAIL"), a much worse outcome than not having DNSSEC at all.
- Key rollover without proper timing — rotating a DNSKEY without respecting TTLs and overlap periods can create a window where old cached signatures don't match the new key, causing validation failures for some resolvers mid-rotation. This is exactly why managed DNSSEC automation exists — the timing details are genuinely easy to get wrong by hand.
- Confusing DNSKEY with the actual signatures — DNSKEY is just the public key; it's the RRSIG records that carry the actual per-recordset signatures verified against it.
- Assuming DNSSEC is "set and forget" — a broken or expired DNSSEC configuration (misrotated keys, expired signatures) causes hard failures for validating resolvers, unlike most DNS misconfigurations which just mean stale or missing data. This makes DNSSEC unusually unforgiving if not maintained correctly.
Comparison & FAQ
| Type | Purpose | Key difference from DNSKEY |
|---|---|---|
| DS | A hash of the DNSKEY, published in the parent zone | Lives one level up, linking trust from parent to child |
| RRSIG | The actual cryptographic signature over a set of records | DNSKEY is the key; RRSIG is what's signed with it |
| NSEC / NSEC3 | Proves a name doesn't exist (authenticated denial) | A different DNSSEC mechanism entirely, unrelated to key publication |
Do I need to manually create DNSKEY records?
No — enabling DNSSEC at your DNS provider generates and manages DNSKEY records automatically. Your manual responsibility is usually just publishing the corresponding DS record at your domain registrar.
What's the difference between a ZSK and a KSK?
A Zone Signing Key signs the zone's regular record data and is typically rotated more often; a Key Signing Key signs the DNSKEY record set itself and anchors the chain of trust to the parent zone via a DS record, so it's rotated less frequently to avoid repeatedly touching that parent-level trust link.
What happens if my DNSKEY and DS record don't match?
Validating resolvers will fail to verify your zone's chain of trust and may return SERVFAIL for the entire domain — a much more severe failure than a typical DNS misconfiguration, since it can make the domain effectively unreachable for anyone using a validating resolver.
Is DNSSEC required for a normal website?
No, it's optional, though increasingly recommended as a defense against DNS spoofing and cache poisoning attacks. Enabling it does add operational complexity (key rotation, keeping the DS record in sync), which is why many smaller sites still don't use it.