Part of the Akamai WAF Defense Guide - Akamai WAF protects web services but DNS infrastructure remains vulnerable to DoS attacks. Understanding attack sequencing, identifying non-scalable infrastructure, and building response procedures for services outside edge protection.

DoS Response Playbook: Why Akamai Protection Doesn't Eliminate Attack Surface

The Protection Gap That Infrastructure Diagrams Don't Show

Enterprise security presentations display comprehensive defense architecture: Akamai edge infrastructure absorbing multi-terabit DDoS floods, Web Application Firewall blocking exploitation attempts, Prolexic scrubbing centers filtering volumetric attacks. Executive teams approve substantial security investment based on these capabilities.

Then DNS infrastructure fails under attack traffic that never reaches Akamai.

Organizations architect edge protection for HTTP/HTTPS services. DNS operates as prerequisite infrastructure - assumed reliable, rarely scrutinized for attack resilience. Security teams configure elaborate application-layer defenses while DNS runs on infrastructure sized for the internet of 2010, not adversarial conditions of 2026.

The architecture assumption: "Akamai handles internet-scale attacks, so our infrastructure doesn't need that capability."

The reality: Attackers probe entire infrastructure topology, not just edge-protected endpoints. DNS represents attractive target precisely because it sits outside expensive security controls.

At a client, comprehensive Akamai deployment protected all customer-facing web services. Security dashboards showed excellent threat mitigation metrics. Then sustained DNS amplification attack overwhelmed authoritative name servers, making all services unreachable despite edge infrastructure functioning perfectly.

The attack didn't target services behind Akamai. It targeted the prerequisite layer that makes those services discoverable.

Why DNS Remains Vulnerable Despite Edge Protection

Modern DNS infrastructure supports multiple deployment models with different resilience characteristics:

Managed DNS Services (Akamai, Cloudflare, AWS Route 53)

Characteristics:

Global distribution with anycast routing
Multi-terabit capacity absorbing volumetric attacks
Built-in DDoS protection included in service
Automatic scaling during traffic surges

Attack resilience: Very high. These platforms designed specifically for internet-scale attack mitigation.

Adoption barrier: Many organizations maintain legacy DNS infrastructure for historical reasons, regulatory requirements, or cost optimization. Migration requires substantial effort.

Self-Hosted Authoritative DNS

Characteristics:

Running on enterprise-managed servers (physical or virtual)
Capacity sized for normal query volume plus modest overhead
Geographic distribution limited to datacenter locations
DDoS protection depends on upstream network provider

Attack resilience: Limited. Infrastructure handles operational load efficiently but lacks capacity to absorb attack traffic.

Prevalence: Common in enterprises with established infrastructure predating cloud services. Often maintained for compliance requirements mandating control over authoritative data.

Hybrid Architectures

Characteristics:

Primary DNS on managed service (scalable, protected)
Secondary DNS on self-hosted infrastructure (organizational requirements)
Split-horizon DNS with internal and external resolution paths

Attack resilience: Depends on configuration. If primary DNS is managed service, resilience is high. If self-hosted secondary becomes preferred resolver during attack, protection degrades.

Complexity risk: Failure modes in hybrid architectures are non-obvious. Organizations discover resilience gaps during actual attacks, not theoretical planning.

The DNS Amplification Attack Pattern

Attackers exploit DNS protocol characteristics to amplify attack traffic:

Basic mechanism:

Attacker sends DNS query with spoofed source IP (victim's IP address)
DNS server responds to spoofed IP (victim receives response)
DNS response significantly larger than query (amplification factor)

Amplification examples:

Query size: 60 bytes
TXT record response: 4,000 bytes
Amplification factor: 66×

Attacker generating 1 Gbps query traffic creates 66 Gbps response traffic directed at victim.

Why Self-Hosted DNS Is Vulnerable

Capacity limitation: Enterprise DNS servers sized for internal query volume (thousands of queries per second). Amplification attacks generate millions of queries per second.

Network bandwidth: Server capacity may be adequate, but network uplink becomes saturated. Attack traffic consumes all available bandwidth before reaching DNS application.

State exhaustion: DNS servers maintain connection state for in-flight queries. Attack floods exhaust connection tables, preventing legitimate queries from being processed.

Geographic concentration: Self-hosted infrastructure typically deployed in 2-3 geographic locations. Attackers can focus traffic on specific sites, overwhelming regional capacity.

Managed DNS services handle these attacks routinely. Self-hosted infrastructure fails under similar load.

Attack Sequencing Intelligence: Understanding Multi-Phase Campaigns

Sophisticated attacks don't target single infrastructure component. They probe systematically, seeking weakest point in defense chain:

Observed Attack Sequence at UK Financial Institution

Phase 1: Reconnaissance

Target: Public DNS infrastructure
Method: Automated queries enumerating subdomains
Volume: 50,000-100,000 queries over 24 hours
Impact: Minimal - within normal capacity

Intelligence gathered:

Record/subdomain inventory (www, api, admin, dev, staging)
Mail server configurations (MX records)
Geographic distribution (geolocation of IP addresses)
Service providers identified (cloud hosting, CDN usage)

Defense visibility: DNS query logs showed unusual enumeration pattern. Security team noted activity but no immediate action required.

Phase 2: Capacity Testing

Target: Edge-protected web services
Method: HTTP flood attempting to overwhelm Akamai - 60-120 seconds
Volume: 2.4 Gbps
Impact: None - Akamai absorbed traffic

Intelligence gathered:

Edge protection confirmed effective
Application response times remain normal
No obvious vulnerability in web layer

Defense visibility: Akamai dashboards showed attack mitigation. Security team documented incident but no service disruption.

Phase 3: Pivot to Infrastructure

Target: Authoritative DNS servers
Method: DNS amplification attack
Volume: 8.7 Gbps (60 seconds bursts)
Impact: Severe - DNS resolution failures

Attack characteristics:

Traffic originated from tens of thousands of compromised IoT devices
Queries targeted large TXT records (DKIM, SPF) for maximum amplification
Geographically distributed sources prevented simple IP blocking
Volume exceeded DNS infrastructure capacity several times over

Service impact:

Almost none - the attack gone before identified

Defense visibility: Network monitoring showed capacity exhaustion but too late to react.

Phase 4: DNS Attack

Target: Authoritative DNS servers
Method: DNS amplification attack
Volume: Variable (4-12 Gbps) sustained
Impact: Severe - DNS resolution failures

Attacker adaptations:

Customer-facing services unreachable (DNS resolution failed)
Akamai edge infrastructure functioning perfectly
Backend systems operational
Service unavailable because DNS couldn't resolve hostnames

This demonstrated: DNS servers unresponsive. Emergency escalation to executive team.

Why Attack Sequencing Matters for Defense

Understanding multi-phase attack methodology enables proactive defense:

Predictive Defense Based on Phase Recognition

When Phase 1 reconnaissance detected:

Traditional response: Log activity, monitor for escalation, no immediate action.

Informed response based on sequencing knowledge:

Reconnaissance indicates attacker building target database
High probability of subsequent capacity testing (Phase 2)
Moderate probability of infrastructure pivot (Phase 3)
Proactive action: Review DNS infrastructure resilience, implement additional monitoring, prepare incident response procedures

Benefit: Instead of reacting to Phase 3 attack in real-time, organization can prepare defenses after Phase 1 observation - they have a chance to adjust their risk appetite to changing DoS patterns.

Domain Name Targeting Patterns

Attackers don't query random domains. They target specific records for operational reasons:

Large TXT records (DKIM, SPF, DMARC) - Maximum amplification factor. Responses can exceed 4KB for complex email authentication configurations.

Wildcard DNS records - If configured, single query pattern generates responses for unlimited subdomain variations. Attacker multiplies request volume without infrastructure.

DNSSEC-signed zones - Cryptographic signatures increase response size substantially. DNSSEC deployment improves security but also increases amplification potential.

ANY queries - Request all record types for domain. Legitimate use rare. Attack usage common for maximum response size.

Defense implications:

Rate limiting by query type: TXT queries rate-limited more aggressively than A record queries. Legitimate applications rarely need high TXT query rates.

Response size limitations: Configure DNS servers to truncate oversized responses, forcing TCP fallback (which has better rate limiting characteristics).

DNSSEC consideration: Security benefit of DNSSEC outweighs amplification risk, but requires infrastructure capacity planning accounting for larger responses.

The Incident Response Playbook

Let's be clear - once you are under a sustained DDoS attack, there is little you can do. Unless you can implement infrastructure changes quickly.

Effective DoS response requires procedures documented before attacks occur:

Detection and Classification

Tier 1: Automated Detection

Monitoring triggers based on:

DNS query rate exceeding baseline by >X multiple
Geographic anomalies (traffic from unexpected regions)
Query type distribution shifts (sudden increase in TXT queries)
Response failure rate increase by Y%

Automated response: Alerts to security operations, traffic data captured for analysis.

Tier 2: Human Analysis

Security analyst evaluates:

Is this attack or legitimate traffic surge? (new product launch, marketing campaign)
What infrastructure is targeted? (web services, DNS, email, specific applications)
Attack sophistication level? (simple flood vs. adaptive campaign)
Business impact? (services degraded vs. fully unavailable)

Decision point: Escalate to incident response team or handle through standard procedures.

Tier 3: Incident Response Activation

Criteria for escalation:

Service unavailability exceeding 15 minutes
Attack traffic exceeding infrastructure capacity
Attacker demonstrating adaptive behavior (evolving tactics)
Executive visibility required (customer impact, regulatory reporting)

Response team: Security operations, infrastructure engineering, network operations, communications.

Tier 4: Cyber-defense Strategy

This slow process of strategy changes may be too slow for today's internet landscape. Still important for long-term business operation:

Monthly / annual attack size changes - comparison with industry data
Targets of attacks - domains / infrastructure
Evaluating capabilities of existing protections

Immediate Mitigation Actions

Step 1: Traffic Analysis (5-10 minutes)

Identify attack characteristics:

Source IP distribution (concentrated or distributed?)
Query patterns (specific records targeted?)
Traffic volume trend (increasing, sustained, decreasing?)
Geographic distribution

Data sources: DNS query logs, network flow data, firewall logs.

Step 2: Rate Limiting Implementation (10-15 minutes)

Per-IP rate limiting:

Accept: 100 queries per minute per IP
Penalty: 5-minute block after threshold violation

Query type rate limiting:

A/AAAA records: 1000 queries/min (normal usage)
TXT records: 100 queries/min (reduce amplification)
ANY queries: 10 queries/min (rarely legitimate)

Geographic rate limiting:

Expected regions: Full rate
Unexpected regions: Reduced rate with CAPTCHA challenge

IP address blocking:

Only effective if the attack is coming from a limited number of IP addresses.

Step 3: Upstream Provider Coordination (15-30 minutes)

Contact network provider:

Request traffic scrubbing if available - off-net scrubbing usually doesn't trigger for 15 mins
Coordinate null-routing if necessary
Implement BGP blackholing for extreme scenarios

Managed DNS failover (if hybrid architecture):

Increase TTL on managed DNS service (reduce load on self-hosted)
Spin up secondary cloud DNS service (if not available) and update authoritative DNS servers
Temporarily disable self-hosted secondary during attack
Monitor managed DNS for capacity

Step 4: Communication Protocols (Ongoing)

Internal stakeholders:

Executive team: Impact summary, estimated restoration timeline
Customer support: Status updates, customer communication guidance
Engineering teams: Technical details, assistance requests

External stakeholders:

Customers: Service status page updates
Regulators: Incident notification if required by compliance
Law enforcement: If attack includes extortion or criminal threats

Sustained Response for Multi-Day Attacks

Daily incident review:

Attack pattern evolution (is attacker adapting?)
Mitigation effectiveness (are defenses working?)
Infrastructure impact (system health, capacity utilization)
Business impact (customer churn, revenue loss, reputation)

Defense refinement:

Adjust rate limiting based on observed patterns
Implement additional filtering as attack evolves
Coordinate with providers for enhanced protection

Documentation:

Maintain timeline of attack progression
Record all mitigation actions and outcomes
Capture lessons learned for post-incident review

Infrastructure Assessment: Identifying Non-Scalable Components

Organizations with Akamai protection often assume comprehensive coverage. Reality assessment requires inventory of services outside edge protection:

DNS Infrastructure Resilience Audit

Questions to evaluate:

Query capacity:
"What is maximum query rate our DNS infrastructure can sustain?"
Typical self-hosted: 50,000-200,000 queries/second
Managed services: Millions of queries/second

Network bandwidth:
"What is available bandwidth for DNS servers?"
Typical enterprise: 1-10 Gbps
Attack traffic: Frequently exceeds 10 Gbps

Geographic distribution:
"How many independent DNS hosting locations exist?"
Minimum recommended: 3
Many enterprises: 1-2

Provider diversity:
"Are all DNS servers with single provider?"
Risk: Provider outage affects all DNS
Best practice: Multiple providers with automatic failover

Email Infrastructure (Often Overlooked)

Mail server capacity:
DoS attacks target mail servers to disrupt business communication. Mail infrastructure rarely sized for attack traffic.

SPF/DKIM record amplification:
Email authentication records can be large (>1KB). Attackers exploit for DNS amplification. Organizations with complex SPF policies face higher risk.

MX record prioritization:
Attackers may target primary mail server specifically. Secondary MX records should have sufficient capacity for failover.

VPN and Remote Access

Capacity limitations:
VPN concentrators sized for normal remote workforce. DoS attack preventing VPN access disrupts remote operations.

Authentication dependencies:
VPN often depends on LDAP, RADIUS, or other authentication services. Attacking authentication infrastructure prevents VPN access even if VPN concentrators remain available.

What We Built at a Client

Initial state: Comprehensive Akamai protection for web services. Self-hosted DNS infrastructure on two servers sized for operational load. No DoS response procedures documented.

Infrastructure improvements:

Hybrid DNS architecture - Migrated primary DNS to Akamai Edge DNS (managed service with DDoS protection). Retained self-hosted secondary for compliance requirements but reduced dependency.

Monitoring enhancement - DNS query pattern analysis with automated anomaly detection. Early warning for reconnaissance activity.

Geographic diversity - Added third DNS hosting location in different geographic region with different network provider.

Response procedures:

Incident playbook - Documented detection criteria, escalation procedures, mitigation actions. Security team knows exactly what to do when DNS attack detected.

Failover procedures - Tested DNS failover from self-hosted to managed service. Validated that services remain accessible if self-hosted infrastructure fails.

Communication templates - Pre-written status page updates, customer notifications, executive briefs. Enables rapid communication during incidents.

Testing validation:

Conducted simulated DoS attack (with controlled traffic source) to:

test detection latency
rate limiting effectiveness - residual traffic to application servers
failover to managed DNS

The Organizational Reality: Testing Is Optional Until It Isn't

Organizations invest in incident response planning. Few test procedures under realistic conditions:

Common assumption: "We have runbook, we're prepared."

Testing reveals:

Contact lists outdated (personnel changed roles)
Credentials for emergency procedures expired or incorrect
Coordination between teams never actually practiced
Communication templates assume circumstances that don't match reality

Recommendation: Quarterly DoS simulation exercises

Not full-scale attacks (expensive, disruptive). Tabletop exercises where teams walk through response procedures, identify gaps, update documentation.

Example scenario: "DNS query rate increased 400% over 10 minutes. What actions do you take?"

Teams discover:

Rate limiting requires firewall change request (2-day approval process)
DNS failover procedure references decommissioned infrastructure
Executive notification list missing current CTO contact

These discoveries during exercise are valuable. During actual incident they're catastrophic.

The UK bank conducted quarterly tabletop exercises. Each revealed 3-5 procedural gaps that got documented and fixed. By fourth exercise, procedures were robust enough to handle actual attacks effectively.

Related Resources

← Back to Akamai WAF Defense Overview - Complete Akamai security guide
Rate Limiting & DDoS → - Rate limiting operational challenges
Site Shield Operations → - Origin protection IP management
Cost of Interruptions → - Incident response operational overhead

References

Cloudflare. (2024). "DDoS Threat Report." Cloudflare Radar. https://radar.cloudflare.com/reports/ddos
Rossow, C. (2014). "Amplification Hell: Revisiting Network Protocols for DDoS Abuse." Network and Distributed System Security Symposium (NDSS).
NIST. (2025). "Guide to DDoS Attacks Prevention and Response." NIST Special Publication 800-189 (Rev. 1 draft).
Akamai Technologies. (2024). "Edge DNS Product Documentation." Akamai TechDocs. https://techdocs.akamai.com/edge-dns/
US-CERT. (2023). "Understanding Denial-of-Service Attacks." Cybersecurity and Infrastructure Security Agency.
van Rijswijk-Deij, R., et al. (2016). "A High-Performance, Scalable Infrastructure for Large-Scale Active DNS Measurements." IEEE Journal on Selected Areas in Communications.
Kührer, M., et al. (2014). "Exit from Hell? Reducing the Impact of Amplification DDoS Attacks." USENIX Security Symposium.
Arbor Networks. (2024). "Worldwide Infrastructure Security Report." NETSCOUT Arbor. https://www.netscout.com/wisr
DNS-OARC. (2023). "DNS Operations Analysis and Research Center Resources." https://www.dns-oarc.net/
Paxson, V. (2001). "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks." ACM Computer Communication Review.