DNSSEC Signing for CDN Infrastructure: Authenticated DNS Without the Performance Hit

Back in 2018, we migrated a top-50 e-commerce domain to our anycast DNS platform with DNSSEC enabled and watched validation failure rates spike to 4% overnight. It wasn't a key typo or a clock skew issue — our signers simply couldn't keep up with the churn of 2 million dynamic edge records, and signatures were expiring before they could propagate. That outage taught me what most DNSSEC guides don't cover: at CDN scale, authenticated DNS isn't a crypto problem, it's an infrastructure and distribution problem.

The Inline Signing Trap: Why Real-Time Signing Fails on Anycast

Most teams start with inline signing because it looks simple. You flip dnssec-policy on in BIND or enable default-publish in PowerDNS, and the nameserver signs responses as they go out. For a single authoritative server handling a few thousand static zones, that works fine. On a CDN with 40+ anycast PoPs, thousands of zones, and records that change every 30 seconds for load shedding and origin health, it falls apart completely. I've seen inline signers push CPU to 85% during a routine purge, causing query latency to jump from 12ms to over 400ms while the HSM throttled.

The core issue is state and consistency. Inline signing requires every edge nameserver to have access to private keys — typically the ZSK — and to generate RRSIGs on the fly. That means replicating sensitive key material to every PoP, increasing your attack surface, and forcing each node to do expensive crypto for every cache miss. When you've got geographically distributed nodes serving 5M QPS, you don't want Ed25519 or ECDSA P-256 operations in the hot path. You want your edge to do what it does best: serve pre-computed, validated answers as fast as possible. This is also where DNS NS Delegation for CDN: Offloading Domain Resolution to Edge Networks decisions matter, because how you delegate subdomains determines where signatures must be generated and validated.

# Don't do this on CDN edge nodes - inline signing in BIND 9
options {
    dnssec-policy "cdn-inline";
};

dnssec-policy "cdn-inline" {
    keys {
        ksk key-directory lifetime unlimited algorithm ed25519;
        zsk key-directory lifetime 30d algorithm ed25519;
    };
    signatures-refresh 5d;
    signatures-validity 14d;
    signatures-validity-dnskey 14d;
    max-zone-ttl 3600;
    zone-max-ttl 3600;
};

# Instead, edge nodes should serve pre-signed zones transferred via AXFR/IXFR
zone "example-cdn.com" {
    type secondary;
    primaries { 10.0.100.5; }; # Hidden primary signer
    file "signed/example-cdn.com.signed";
    auto-dnssec off; # Validation only, no signing on edge
};

Hidden Primary Architecture: Separating Signing From Serving

The pattern that's held up for us for the last six years is a classic hidden primary model, but tuned for CDN workflows. We run a small cluster of offline (really, isolated) signers — three nodes in two regions, none of them announced via anycast — that hold all KSK and ZSK private keys in an HSM. They ingest zone updates from our control plane, sign the entire zone, and then distribute the fully signed zone files to the global anycast fleet via incremental transfers. Edge nodes never see a private key. They just serve what they're given, which means a PoP compromise doesn't turn into a key compromise.

Key segregation is non-negotiable here. We use a double-signature ZSK rollover with algorithm 13 (ECDSA P-256) for broad resolver compatibility, and algorithm 15 (Ed25519) for modern validators, publishing both. KSKs live for 12 months and are rolled with RFC 5011 timing plus manual DS update at the parent; ZSKs rotate every 60 days automatically. The signers pre-generate RRSIGs with jittered inception and expiration times to avoid the thundering herd where millions of signatures expire at the same second. If you're handling apex records that point to CDN edges, you'll want to pair this with DNS CNAME Flattening: Pointing Root Domains to CDN Without Breaking DNS Rules carefully, because flattened records still need to be signed at the authoritative level, not synthesized unsigned at the edge.

#!/bin/bash
# Offline signer workflow - executed on hidden primary, not edge
# Uses ldns and OpenDNSSEC-style key management

ZONE="example-cdn.com"
KEY_DIR="/var/lib/knot/keys"
UNSIGNED="/var/lib/zones/${ZONE}.unsigned"
SIGNED="/var/lib/zones/${ZONE}.signed"

# 1. Generate new ZSK if within rollover window (check via policy DB)
/usr/sbin/ksk-rollover-check --zone $ZONE --alg ed25519 --lifetime 60d

# 2. Sign with both algorithms, with validity jitter
ldns-signzone -n -p -s $(shuf -i 0-3600 -n 1) \
  -e 1209600 \  # 14 days validity
  -i 86400 \    # 1 day jitter on inception
  -f $SIGNED $UNSIGNED \
  K${ZONE}.+015+*.key K${ZONE}.+013+*.key

# 3. Verify before distribution
ldns-verify-zone $SIGNED || exit 1

# 4. Notify distributors - edges pull via IXFR with TSIG
knotc zone-notify $ZONE && knotc zone-flush $ZONE

Quantifying the Cost: What DNSSEC Really Does to Edge Performance

There's a persistent myth that DNSSEC kills performance. It doesn't have to, if you keep signing off the edge. The overhead shifts from CPU on every query to zone size and transfer bandwidth. A signed response is larger — an A record answer goes from ~80 bytes to ~450 bytes with RRSIGs — which pushes more answers over UDP truncation limits and forces TCP fallback. When we first enabled DNSSEC across our entire anycast fleet, we saw TCP query share jump from 0.8% to 6.2%. We had to retune our edge daemons for higher TCP connection reuse and bump our edns-udp-size handling.

The other place it shows up is in provisioning. With EDNS Client Subnet for CDN Geolocation: Routing Users to the Nearest Edge, we generate scoped answers per /24. You can't pre-sign every possible ECS variant. Our approach is to sign the base record sets and return a single covering RRSIG with a short TTL (60s) for ECS-scoped responses, acknowledging that ECS + DNSSEC will always be a trade-off. Per the HTTP Working Group Specifications and modern web.dev Articles on secure transport, many clients will validate at the stub resolver, so you want deterministic, cacheable signed answers rather than dynamic per-client signatures.

Putting It Into Practice: Automated Pre-Signing and Distribution Pipeline

We’ve settled on pre-signing with a hidden primary for a reason — it’s the only way you keep signing crypto off the hot path. In production, that looks like a locked-down signer box (ideally air-gapped or at least not anycast-announced) that holds your KSK in an HSM and your ZSK either in the HSM or on encrypted disk with tight ACLs. We run Knot DNS 3.3 and BIND 9.18 hidden primaries for different zones, but the pattern’s identical: a cron or systemd timer pulls the unsigned zone from your provisioning system, signs it with ECDSAP256SHA256 (algorithm 13), and pushes the signed zone out via AXFR/IXFR. For a 1.8M record e-commerce zone, inline signing was pegging our edge CPUs at 78% during re-sign bursts. Pre-signing the same zone takes 41 seconds on a single 4-core signer and edge CPU stays flat at 6-8%.

Distribution is where most teams stumble. Don’t just AXFR a full 900MB signed zone every 24 hours to 60 PoPs — you’ll saturate your transfer mesh and spike reload latency. Use incremental transfers and keep your RRSIG lifetimes generous. We set rrsig-lifetime 14d with rrsig-refresh 7d, so we only re-sign once a week but signatures stay valid for two weeks. That gives us breathing room if the signer goes down. Our catalog zones then replicate to edge secondaries in about 18-22 seconds via IXFR, instead of 11-14 minutes for a full AXFR. We also monitor RRSIG expiry like it’s a TLS cert — Prometheus alert fires if rrsig_expire < now() + 72h. If you’re already handling malicious domain filtering at the edge, this pairs cleanly with DNS Sinkholing at CDN Scale: Redirecting Malicious Traffic for Analysis since both rely on authoritative data being consistent across edges.

# /etc/knot/knot.conf - Hidden Primary Signer (not announced via anycast)
policy:
  - id: cdn-ecdsa-policy
    algorithm: ecdsap256sha256
    ksk-size: 256
    zsk-size: 256
    ksk-lifetime: 365d
    zsk-lifetime: 30d
    rrsig-lifetime: 14d
    rrsig-refresh: 7d
    rrsig-pre-refresh: 2d
    propagation-delay: 300
    nsec3: on
    nsec3-iterations: 0
    nsec3-opt-out: off
    nsec3-salt-lifetime: 30d

zone:
  - domain: cdn.example.com
    storage: /var/lib/knot/zones
    file: cdn.example.com.unsigned
    dnssec-signing: on
    dnssec-policy: cdn-ecdsa-policy
    zonefile-sync: -1
    journal-content: all
    serial-policy: dateserial

# Verify before distribution - fails transfer if signatures invalid
# knotc zone-sign cdn.example.com && ldns-verify-zone cdn.example.com.signed

Advanced Patterns: Rollovers, NSEC3 Tuning, and Debugging SERVFAIL

Key rollovers will bite you if you treat them like a normal deploy. We learned this the hard way when a ZSK rollover left 12% of resolvers returning SERVFAIL for 40 minutes. You’ve got to double-sign. For a ZSK rollover (which you’ll do every 30-90 days), publish the new ZSK DNSKEY, wait at least propagation-delay + TTL (we use 600s delay + 300s TTL + safety margin = 30 minutes), then start signing with the new ZSK while still serving RRSIGs from the old one for another TTL period. Don’t retire the old ZSK until you’ve confirmed dnsviz.net and Verisign’s debugger show both chains validating. And please, use ECDSA P-256 instead of RSA-2048 — your responses drop from ~1,280 bytes to ~680 bytes, which keeps you under the 1,232-byte UDP safe limit and avoids the TCP fallback penalty that adds 45-80ms.

NSEC vs NSEC3 is another trade-off folks get wrong. NSEC is faster and smaller (about 15% less overhead per negative response), but it lets anyone walk your zone. If you’re hosting customer vanity domains or have sensitive subdomains, NSEC3 with iterations: 0 is non-negotiable — iterations above 0 just burn resolver CPU (RFC 9276 explicitly says set it to 0) and increase your response size by ~30 bytes per NSEC3 record. We saw validation failures spike to 0.4% when we tested iterations=10 under load. Keep it at 0, rotate the salt monthly if you need zone privacy. And remember, larger signed responses make you a better amplifier if you don’t lock down recursion — that’s why DNS Amplification Attack Mitigation: Protecting CDN DNS Infrastructure should be part of the same hardening sprint as DNSSEC.

When validation breaks, it’s almost always one of three things: expired RRSIGs, clock skew, or broken delegation chain. Check dig +dnssec +multi for missing RRSIGs and delv @8.8.8.8 yourdomain for the actual validator error. We’ve had edges serve stale signatures because NTP drifted by 4 minutes — RRSIG inception was in the future from the resolver’s perspective. We now run chrony with maxdistance 1.0 and alert if drift exceeds 500ms. The other classic is DS record mismatch after a KSK rollover; automate DS updates via CDS/CDNSKEY (RFC 7344) and verify at the parent. If you’re also automating health checks for failover, tie DNSSEC monitoring into that same system described in DNS Failover Automation for CDN: Automatic Rerouting When Origins Go Down so a failed validation automatically triggers a PoP withdrawal rather than blackholing clients.

Frequently Asked Questions