Detecting DNS DDoS Attacks: Sentinel and GuardDuty Detections
Retrospective: this article looks back at events from October 2016, written in 2026 with the benefit of hindsight.
DDoS attacks against DNS and web front ends are noisy, which makes them easy to notice and hard to diagnose quickly. The goal of detection is speed: confirm it is an attack, identify the target, and trigger your response before customers flood the help desk.
Signals worth watching
- A sudden spike in DNS query volume or in requests per second to a public endpoint.
- Rising error rates (timeouts, 5xx responses) from your load balancers or CDN.
- Large numbers of requests from a small set of autonomous systems, countries or user agents.
- Health-check failures for one region while others remain healthy.
Where the data lives
AWS: CloudFront and Application Load Balancer access logs, AWS WAF logs, Route 53 query logs, CloudWatch metrics, and — with Shield Advanced — DDoS event metrics and notifications. GuardDuty is focused on threats to your account (credential misuse, malicious IPs, crypto mining) rather than volumetric DDoS, so do not rely on it alone here.
Azure: Azure Front Door and Application Gateway WAF logs, Azure DDoS Protection metrics and diagnostic logs, and Azure Monitor alerts.
Bringing it into Microsoft Sentinel
Connect WAF and Front Door diagnostics to your Log Analytics workspace, and use the Amazon Web Services connectors for AWS logs. A simple starting query for an Azure Front Door WAF log looks for request spikes by client IP:
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| summarize Requests = count() by clientIP_s, bin(TimeGenerated, 5m)
| where Requests > 1000Tune the threshold to your normal traffic.
Response
Detection only helps if the next step is clear: who declares an incident, who contacts the provider's DDoS response team, and which rate-limiting or geo-blocking rules can be applied immediately. Write that down before you need it.