DNSSEC (DNS Security Extensions)

DNSSEC (DNS Security Extensions) is a set of protocol extensions. It adds digital signatures to DNS data. A validating resolver can then prove that an answer came from the zone that owns the name. It can also prove the answer was not modified on the way. DNSSEC provides origin authentication and integrity protection for DNS data. It also provides a means of public key distribution (RFC 4033 section 1). This includes authenticated denial of existence, signed proof that a name or type does not exist (RFC 4033 section 3). DNSSEC is not encryption. RFC 4033 states plainly that these extensions do not provide confidentiality (RFC 4033 section 1). So queries and answers stay readable to anyone on the path. Query privacy needs DNS over HTTPS (DoH) or DNS over TLS (DoT) alongside DNSSEC, not instead of it. DNSSEC is also not a defence against denial of service. It does not cover zone transfers or dynamic updates (RFC 4033 section 4). And it does not protect the DNS message header (RFC 3833 section 2.1). It only works when both ends cooperate: the zone must be signed and the resolver must validate. The core specification is RFC 4033, RFC 4034 and RFC 4035 (RFC 9364 section 2), extended by RFC 6840 (RFC 9364 section 2.1). RFC 9364, also called BCP 237, states that using DNSSEC is the best current practice for origin authentication of DNS data (RFC 9364 section 1.1).

How it works

Signing. A zone administrator generates one or more public/private key pairs. The administrator signs the zone's authoritative RRsets with the private keys (RFC 4035 section 2.1). The signatures go into RRSIG records (RFC 4033 section 3.1). The public keys go into DNSKEY records (RFC 4034 section 2). DNSSEC adds four record types: DNSKEY for public keys, RRSIG for signatures over a set of records, NSEC for signed proof that a name or type does not exist, and DS for delegation signer. It also adds two header bits, Authenticated Data (AD) and Checking Disabled (CD) (RFC 4034 section 1, RFC 4033 section 3). By convention a zone runs two kinds of key. A Key Signing Key (KSK) signs the zone's other keys. A Zone Signing Key (ZSK) signs the zone data (RFC 4033 section 2).

Chain of trust. The parent zone publishes a DS record. This is a digest of the child's key-signing DNSKEY, signed by the parent. Each signed delegation binds a zone to the one above it (RFC 4033 section 3.1). A validating resolver starts from a trust anchor it holds out of band, normally the public key for the root. It walks down the chain, checking at each step that the zone's DNSKEY matches the parent's DS and that the signatures verify (RFC 4033 section 3.1). The root zone has been signed since 2010. That is what lets the chain start at the top (RFC 9364 section 2.1). The root key was rolled in 2018, using the automated trust-anchor update mechanism of RFC 5011 (RFC 9364 section 4).

Result. A resolver sorts every answer into one of four states. Secure means a chain of signed DNSKEY and DS records reaches it from a trust anchor. Insecure means no such chain exists, typically because the name sits in or under an unsigned zone. Bogus means a chain should exist but signatures fail or records are missing. The fourth state is Indeterminate (RFC 4035 section 4.3). For a Secure answer a recursive server sets the AD bit. To avoid confusing legacy clients, it does this only when the query itself asked for it, by setting the DNSSEC OK (DO) bit or the AD bit (RFC 4035 section 3.2.3, RFC 6840 section 5.8). Be careful reading this in dig. dig sets the AD bit in its own queries by default, so ad can appear in the flags without +dnssec (BIND 9 manual). What +dnssec adds is the DO bit, and that is what makes the server send the RRSIG records back. For a Bogus answer the recursive server must return RCODE 2 (SERVFAIL) to the client. It returns the full unvalidated response only if the query had the CD bit set (RFC 4035 section 5.5).

Proving absence. Negative answers are signed too. Authenticated NSEC records prove that a record is not present in a signed zone (RFC 4035 section 5.4). NSEC3 does the same over hashed names (RFC 5155 section 1.1). Compact Denial of Existence answers a nonexistent name with a single minimally covering NSEC or NSEC3 record. This suits servers that sign on the fly (RFC 9824).

Because the data itself is authenticated, other protocols can build on it. DANE lets a domain publish the keys its TLS servers use (RFC 6698). A client may only act on a TLSA record whose DNSSEC validation state is Secure. Insecure or indeterminate TLSA records are unusable (RFC 6698 section 4.1). So DANE is only available on a signed zone.

Why it matters for a CDN

Every request to a CDN-served hostname starts with a DNS lookup. The record that decides where the client connects is usually a CNAME, pointing your name at the CDN's edge hostname (Fastly documentation). At the zone apex a CNAME is not allowed, so providers substitute their own mechanism. Akamai's zone apex mapping resolves apex lookups to an optimal edge address, using the private AKAMAICDN record type (Akamai Edge DNS features). Fastly declines CNAME flattening altogether. It says it does not recommend the proprietary ALIAS or ANAME features some DNS providers offer, and instead publishes anycast IP addresses you point apex A and AAAA records at (Fastly apex domains). Which mechanism you use decides how much of the lookup your own signatures cover. An A or AAAA record at your apex is an authoritative RRset in your zone, and is signed with your keys (RFC 4035 section 2.1). A CNAME, by contrast, hands the final address lookup to the CDN's zone.

That first lookup is the weak link. A DNS query or response normally travels as a single unsigned, unencrypted UDP packet. This makes interception and spoofing easy for an attacker who can see the traffic (RFC 3833 section 2.1). An off-path attacker can try to guess the query ID and port instead (RFC 3833 section 2.2). Resolvers are no longer as exposed as RFC 3833 described in 2004. Resolver implementations must now use an unpredictable source port and query ID (RFC 5452 section 9.2). RFC 5452 describes these measures as making spoofing many orders of magnitude harder (RFC 5452). But those measures are explicitly only complementary to cryptographic protection, which covers a larger class of attacks (RFC 5452 section 10). DNSSEC, used properly, is the end-to-end data integrity check between the zone administrator and the resolver (RFC 3833 section 2.1). Without it, a forged answer silently sends your users to someone else's server instead of the CDN edge. RFC 3833 singles out CNAME, NS and DNAME records as the worst case in a cache-poisoning attack. That is precisely because they redirect a victim's query to a location of the attacker's choosing (RFC 3833 section 2.3). The CNAME is the record a CDN setup depends on.

The chain stops where the signing stops. Signing your own zone authenticates your records, including the CNAME that points at the CDN. It does not authenticate the CDN's zone. If any delegation in the path is unsigned, the answer is Insecure, not Bogus (RFC 4035 section 4.3). Insecure means unauthenticated, not rejected. In practice the major edge zones are unsigned. As of 2026, dig DS cloudfront.net, dig DS fastly.net and dig DS akamaiedge.net all return nothing. dig +dnssec answers for names in them come back without the ad flag. So the realistic goal is not 'sign every zone in the path', which you cannot do. It is to sign the zone you control, and to know that the final address lookup inside the CDN's zone is unauthenticated. Check the state yourself with dig rather than assuming it.

Two further boundaries are worth being explicit about. DNSSEC authenticates the DNS data that steered the client. It does not authenticate the connection that follows. That is TLS's job. DNSSEC also does not sign the DNS message header (RFC 3833 section 2.1). So the AD bit a stub resolver sees is a claim by its recursive resolver, not cryptographic proof. Trusting it means trusting that resolver and the path to it.

What CDNs do

• Cloudflare: opt-in per zone. Enabling DNSSEC makes Cloudflare sign the zone, publish the public signing keys, and generate the DS record for your registrar. Algorithm 13 (ECDSA Curve P-256 with SHA-256) is its preferred choice. DS records are added automatically for domains on Cloudflare Registrar, and for .ch and .cz (Cloudflare DNSSEC documentation). Cloudflare also publishes CDS and CDNSKEY records, so registrars that support RFC 8078 can maintain the DS record for you (Cloudflare validation and keys). Its negative answers use Compact Denial of Existence instead of NSEC3. NSEC3 is available only on the Enterprise plan (Cloudflare NSEC3 support).
• AWS Route 53: opt-in per hosted zone. Every response for the hosted zone is then signed. The KSK is an asymmetric customer-managed key in AWS KMS that you own and rotate, while Route 53 manages the ZSK. Signing caps record TTLs in that zone at one week, leaving shorter TTLs untouched. Multi-vendor configurations are not supported (Route 53 DNSSEC documentation). Route 53 signs non-DNSKEY records online, generating an RRSIG specific to each response. It proves nonexistence with a compact method that prevents zone walking (Route 53 proofs of nonexistence).
• Google Cloud DNS: opt-in per managed zone. Cloud DNS then manages creation and rotation of the DNSKEY records, and signs zone data with RRSIGs. You still add the DS record at your registrar. Full protection also needs a validating resolver. If your registrar cannot publish a DS record, enabling DNSSEC in Cloud DNS has no effect (Cloud DNS DNSSEC overview).
• Akamai Edge DNS: a contract feature. The Edge DNS contract must include the Security option, then DNSSEC is enabled per zone. Sign and Serve hands signing, serving and key rotation to Akamai. It rotates the ZSK weekly and the KSK annually, uses prepublish rollover, and keeps signatures valid three days with the zone re-signed at least daily. ECDSA-P256-SHA256 is the recommended algorithm. Serve leaves signing and rotation to you for a secondary zone, and Akamai only serves it. Alias zones cannot be signed (Akamai enable DNSSEC, Edge DNS features).
• Fastly: not a DNS provider, so it publishes no zone-signing service. Your zone stays with your DNS provider. Signing the records that point at Fastly's hostnames is that provider's job (Fastly documentation).

The pattern behind the detail: a provider whose answers are computed per query, such as latency or geographic steering or health-based failover, cannot ship a pre-signed static zone file for those records. So it signs online, and uses compact denial of existence for negative answers (Route 53, RFC 9824).

Watch out for

• DNSSEC is not privacy. It is explicitly not designed to provide confidentiality. So an observer on the path still sees the names being queried (RFC 4033 section 4). DoT encrypts the stub-to-recursive hop with TLS; that is the scope RFC 7858 addresses (RFC 7858). DoH carries the same queries inside HTTPS (RFC 8484). They are complements to DNSSEC, not substitutes. Neither tells you whether the answer is authentic.
• A validation failure is an outage, not a warning. When signatures do not validate, a validating recursive resolver must return SERVFAIL. It returns the data only to a client that set the CD bit (RFC 4035 section 5.5). Non-validating resolvers keep answering. So the breakage looks intermittent, and depends on the user's resolver. The usual causes are operational rather than hostile: failure to re-sign a zone, clock skew, or botched key or DS changes (RFC 4035 section 4.7). Such incidents drive resolvers into aggressive retries. That is why caching those failures went from optional to advised to mandatory. RFC 4035 allowed a resolver to cache invalid signatures. RFC 6840 raised that to a SHOULD (RFC 6840 section 3.1). RFC 9520 now requires it: security-aware resolvers MUST cache DNSSEC validation failures (RFC 9520 section 3.4).
• Rollovers and migrations are timing-critical. The DS record lives in the parent zone with its own TTL. Validating resolvers will SERVFAIL if you change nameservers before the old DS TTL has expired, because the cached DS no longer matches the new keys (Cloudflare DNSSEC documentation). Akamai likewise requires you to remove the existing DS record and wait out its TTL, before enabling Sign and Serve on an already-signed zone (Akamai enable DNSSEC). RFC 7583 covers the timing of key-rollover events (RFC 9364 section 5). The documented onboarding sequence is therefore to disable DNSSEC at the registrar before repointing nameservers at a new provider. The exception is when both providers can exchange DNSKEY records and you migrate through multi-signer (Cloudflare DNSSEC documentation). Delegated subdomains have their own trap. If the provider hosting the parent zone does not answer DS queries authoritatively, enabling DNSSEC on the child makes the child unresolvable (Route 53 DNSSEC documentation).
• Signed denial leaks, or changes, what your tooling sees. A plain NSEC chain lists every name in the zone, so anyone can walk it (RFC 5155 section 1.1). NSEC3 hashes the names. But recent studies show that hashing gives only moderate protection, and extra iterations do not help against an offline dictionary attack (RFC 9276 section 2.3). Minimally covering records, as used by Compact Denial of Existence, do prevent enumeration. But a zone using them never returns NXDOMAIN to a DNSSEC-enabled query. It answers NOERROR/NODATA instead, and blocks the aggressive negative caching of RFC 8198 (RFC 9824 section 6). Monitoring or code that keys on NXDOMAIN needs to know that.
• Responses get bigger. Signatures and keys enlarge messages. That is why DNSSEC requires EDNS0 and the DO bit (RFC 4033 section 3). RFC 4035 requires a resolver's IP layer to handle fragmented UDP correctly (RFC 4035 section 4.1). But current guidance is to avoid fragmentation instead: keep UDP payloads within about 1400 bytes, drop fragmented DNS responses rather than reassembling them, and fall back to TCP (RFC 9715 section 3.1, RFC 9715 section 3.2). Non-compliant middleboxes between resolver and server remain a known source of validation failures (RFC 9364 section 5).
• Protection is conditional at both ends. RFC 9364 reported in February 2023 that fewer than 10% of the domain names used for websites were signed. It also reported that only around a third of queries to recursive resolvers were validated (RFC 9364 section 1.1). Signing your zone protects only the users behind validating resolvers.

Best practice

• Sign, publish the DS, then verify rather than assume. Sign the zone that holds your CDN hostnames, publish the DS record at your registrar, and confirm the result with the commands in the Examples above. But read the ad flag for what it is. It is the recursive resolver's assertion that it validated the answer (RFC 4035 section 3.2.3, RFC 6840 section 5.8). RFC 4035 warns there is little practical value in checking it beyond debugging. A stub resolver must not rely on validation done on its behalf, unless it reached that resolver over a secure channel (RFC 4035 section 4.9.3). delv is the stronger check. That is because it runs the same resolver and validator logic as named against its built-in root trust anchor, so what it returns is either fully validated or unsigned (BIND 9 manual). Check the CDN's own edge zone with dig DS, so you know where the authenticated part of the lookup ends.
• Take algorithms from the registry, not from a fixed RFC. RFC 9904 obsoleted RFC 8624 in November 2025. It moved the canonical algorithm requirements out of an RFC and into the IANA DNSSEC registries, so the registry is the thing to check (RFC 9904, IANA DNS Security Algorithm Numbers). The registry currently marks RSASHA256 (8), ECDSAP256SHA256 (13) and ED25519 (15) as RECOMMENDED for signing, with 8 and 13 mandatory to implement. Where several are RECOMMENDED, the choice is local policy (RFC 9904 section 3). SHA-1 is finished. RSASHA1 and RSASHA1-NSEC3-SHA1 (5 and 7) must not be used to create DNSKEY, RRSIG or DS records, and validating resolvers must treat them as insecure (RFC 9905 section 2). For the DS digest itself, SHA-256 (2) is recommended, and SHA-1 (1) must not be used for a delegation (RFC 9904 section 4). ECDSA P-256 is what the major providers default to.
• Automate the DS record. Publishing CDS and CDNSKEY records lets a registrar that implements RFC 8078 pick up key changes and update the DS at the registry. This removes the most common source of rollover outages (RFC 9364 section 4, Cloudflare validation and keys). Where the registrar does not support it, plan the rollover on the DS TTL by hand, and follow RFC 7583's timing (RFC 9364 section 5).
• For multiple DNS providers, use multi-signer. Consider a multi-CDN or multi-provider DNS setup where each provider signs with its own keys. Here, the DNSKEY set each one serves must contain the public part of every ZSK for the zone plus its own KSKs, so resolvers can validate an answer from any of them (Edge DNS features). RFC 8901 describes the deployment models and key-management requirements (RFC 9364 section 5). Some managed setups rule it out. Route 53 does not support multi-vendor configurations with signing enabled (Route 53 DNSSEC documentation).
• If you must use NSEC3, set zero iterations and no salt. Prefer NSEC unless you specifically need NSEC3. If NSEC3 is required, an iterations count of 0 must be used, and a zero-length salt is recommended. That is because extra iterations only add CPU cost and interoperability risk, without meaningfully raising the bar (RFC 9276 section 3.1).
• Pair it with privacy, and monitor it. Add DoH or DoT for query privacy. Alarm on validation errors: Route 53 recommends a CloudWatch alarm on DNSSECInternalFailure and DNSSECKeySigningKeysNeedingAction (Route 53 DNSSEC documentation). And keep negative trust anchors (RFC 7646) in mind, as the way to disable validation for one broken domain while it is repaired (RFC 9364 section 5).