Product deep dive
Edge DNS & DNS Security
DNS is the first request of every session and a single point of failure for everything downstream. Akamai splits the problem into authoritative resilience (Edge DNS, DNS Shield, GTM) and outbound resolution security (protective/recursive DNS).
The DNS risk surface
| Threat | Mechanism | Primary control |
|---|---|---|
| Authoritative DNS DDoS | Query flood or random-subdomain (water torture) flood exhausting nameserver capacity | Massively distributed anycast authoritative DNS |
| Cache poisoning / spoofing | Forged UDP answers accepted by a resolver | DNSSEC validation, source-port randomisation, 0x20 encoding |
| Domain hijack | Registrar account compromise or unauthorised NS/DS change | Registry lock, MFA on registrar, change alerting |
| Zone data leakage | Open AXFR, over-broad TXT records, internal hostnames in public zones | Transfer ACLs, zone hygiene reviews |
| Subdomain takeover | Dangling CNAME to a deprovisioned cloud resource | Continuous record inventory and validation |
| Malware C2 / exfiltration over DNS | Outbound resolution to attacker-controlled domains, data tunnelled in labels | Protective/recursive DNS with threat intelligence |
Edge DNS — authoritative resolution
Edge DNS is a fully managed authoritative DNS service running on Akamai's globally distributed anycast network. Its defining property for security is architectural: attack traffic aimed at your zone lands on hundreds of points of presence simultaneously, so no single site absorbs the full load. A flood that would obliterate a pair of self-hosted nameservers is diluted across the platform.
Core capabilities
- Anycast, multiply-redundant delivery across independent name server sets, engineered so that failure or attack on one set does not remove resolution.
- Primary or secondary operation — run Edge DNS as your primary zone host, or as a secondary receiving AXFR/IXFR from your hidden primary. Secondary mode is the low-risk on-ramp: you keep your existing provisioning workflow and gain a resilient serving tier.
- Zone apex support — alias/ANAME-style records that let
example.com(not justwww) point at a CDN hostname, which plain CNAME cannot do at the apex. - DNSSEC signing — automated online signing and key rollover, removing the operational fragility that causes most DNSSEC outages.
- API and IaC control — zones and records managed programmatically, so records live in version control and changes are reviewable.
- Query analytics — per-zone, per-record-type query telemetry, the basis for spotting NXDOMAIN storms early.
DNSSEC operational notes
DNSSEC gives resolvers cryptographic proof that an answer came from the zone owner and was not modified. The failure modes are almost always operational rather than cryptographic:
- Expired signatures — RRSIGs have validity windows; if resigning stops, the zone goes dark for validating resolvers. Managed signing removes this class of incident.
- DS/KSK mismatch — the DS record at the parent must match the current KSK. Rollovers must be sequenced, with TTLs respected at each stage.
- NSEC vs NSEC3 — NSEC proves non-existence but permits zone walking; NSEC3 hashes the names to make enumeration expensive. Use NSEC3 for zones whose record names are themselves sensitive.
- DNSSEC is not encryption — queries and answers remain visible. Use DoT/DoH for confidentiality.
Resilience patterns
- Multi-provider authoritative DNS — delegate to two independent providers with synchronised zones. This survives a total provider outage, at the cost of more complex change management and DNSSEC coordination.
- TTL strategy — 300s for records fronting production endpoints (fast failover), longer for stable infrastructure. Do not lower every TTL to 30s “just in case”; you multiply query volume and therefore your DDoS exposure.
- Registry lock at the registrar, plus MFA and alerting on NS/DS changes. A hijacked delegation defeats every other control you own.
DNS Shield
DNS Shield places a dedicated caching and filtering tier between recursive resolvers and authoritative infrastructure. The value is twofold: it absorbs abusive query patterns (particularly random-subdomain floods that are uncacheable by design) before they reach authoritative servers, and it shortens the resolution path from major ISP resolver networks, improving both latency and reliability for real users.
Global Traffic Management
GTM is DNS-based load balancing and failover: liveness and performance checks decide which answer a resolver receives. Security relevance:
- Automatic failover away from a datacentre that is under attack or degraded, without a human in the loop.
- Geographic and weighted steering to shed load or route a region to scrubbing during an incident.
- Health-check driven withdrawal of an origin that is failing, preventing a partial outage from becoming a total one.
Remember the constraint: DNS-based steering is only as fast as the TTL and as accurate as the resolvers' behaviour — some resolvers and clients ignore TTLs. Plan for a tail of traffic that continues to hit the old answer.
Protective / recursive DNS — the outbound direction
Everything above protects inbound resolution of your names. Protective DNS addresses the opposite direction: what your users, servers and IoT devices resolve on their way out. Because virtually all malware performs DNS lookups — for command-and-control, for payload staging, or to tunnel stolen data — the recursive resolver is a uniquely efficient enforcement point.
What it blocks
- Command-and-control domains — resolution is refused or sinkholed, cutting the malware off before any TCP session exists.
- Phishing domains — including newly registered and typosquatted lookalikes, which are heavily weighted by risk scoring.
- DNS tunnelling / exfiltration — detected by entropy, label length, query rate and record-type anomalies (excessive TXT/NULL queries to a single domain).
- DGA (domain generation algorithm) traffic — high-volume NXDOMAIN patterns with algorithmically random labels.
- Acceptable-use categories — policy enforcement per user group or location.
Deployment considerations
- Point your forwarders and DHCP-advertised resolvers at the protective service, and block outbound port 53 to everything else — otherwise malware simply uses its own resolver. Also consider blocking or controlling known DoH endpoints, which bypass DNS policy over 443.
- Start in monitor mode to discover legitimate long-tail domains before enforcing.
- Feed resolver logs into the SIEM: DNS telemetry is one of the highest-signal, lowest-volume detection sources available.
- Expect false positives on newly registered domains used by legitimate marketing campaigns; have a fast allow-list path.
DNS security checklist
- Inventory every zone and every record; hunt dangling CNAMEs monthly.
- Registry lock plus MFA at the registrar; alert on NS and DS changes.
- Authoritative DNS on anycast with capacity far beyond your peak; consider multi-provider.
- DNSSEC signed with managed key rollover; monitor signature expiry externally.
- Disable open AXFR; restrict transfers to known secondaries.
- CAA records to constrain which CAs may issue for your domain.
- Deliberate TTL policy documented per record class.
- Protective recursive DNS outbound, with port 53 egress locked down.
- Monitor query volume, NXDOMAIN ratio and response codes; alert on deviation.