AWS Route 53 Security: Protecting Your DNS Infrastructure

DNS as a Security Layer

DNS is the foundation of your internet infrastructure, and it's often overlooked from a security perspective. Route 53 sits at the entry point for every user request — a compromised DNS configuration can redirect all your users to a phishing site, expose your internal infrastructure, or allow attackers to obtain legitimate TLS certificates for your domains.

This guide covers the Route 53 security controls that prevent DNS-based attacks and the monitoring patterns that detect when something is wrong.

DNSSEC: Protecting Against DNS Spoofing

DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that the response they received came from the authoritative server and hasn't been tampered with. Route 53 supports DNSSEC signing for both Route 53-hosted zones and Route 53-registered domains.

Enabling DNSSEC:

aws route53 enable-hosted-zone-dnssec --hosted-zone-id Z1234567890

After enabling, Route 53 generates a key-signing key (KSK) and creates a DS record that you need to add to your registrar (or Route 53 if you're also the registrar). This creates a chain of trust from the root DNS zone to your domain.

Monitor DNSSEC health in CloudWatch — Route 53 publishes metrics for DNSSEC key status, and you should alert on DNSSECInternalFailure or DNSSECKeySigningKeysNeedingAction.

Subdomain Takeover Prevention

Subdomain takeover is one of the most common DNS-based vulnerabilities. It occurs when you have a DNS record pointing to a cloud resource (S3 bucket, CloudFront distribution, Elastic Beanstalk environment, EC2 Elastic IP) that no longer exists. An attacker can claim that resource and serve content under your subdomain.

Common vulnerable patterns:

• CNAME to S3 bucket URL for a bucket that's been deleted
• CNAME to Elastic Beanstalk environment that's been terminated
• CNAME to a GitHub Pages or Heroku URL that's been released
• A record pointing to an Elastic IP that's been released

Detection approach: periodically scan all your Route 53 records, attempt to resolve the target, and alert on CNAMEs or A records that resolve to provider-controlled name spaces but where the resource no longer responds. AWS provides a Config rule route53-no-dangling-cname that checks for common patterns.

The prevention is simple: delete DNS records when you decommission the resources they point to. This sounds obvious but is frequently missed during infrastructure teardown.

Route 53 Query Logging

Route 53 query logging captures every DNS query for your hosted zones — the domain requested, the response, and the IP of the requester. This data is valuable for:

• Detecting DNS-based data exfiltration (high volumes of DNS queries to unusual subdomains)
• Identifying compromised hosts making unexpected DNS lookups
• Debugging DNS resolution issues
• Security forensics after an incident

Enable query logging for all public hosted zones:

resource "aws_route53_query_log" "main" {
  cloudwatch_log_group_arn = aws_cloudwatch_log_group.dns_logs.arn
  zone_id                  = aws_route53_zone.main.zone_id
}

Query logs are sent to CloudWatch Logs. Use Logs Insights to analyze patterns. GuardDuty also analyzes Route 53 logs for threats like DNS tunneling and C2 communication — ensure GuardDuty is enabled to get this coverage. See our GuardDuty setup guide.

IAM Controls for Route 53

Unauthorized changes to DNS records can be catastrophic — redirecting all traffic to an attacker's servers, for example. Restrict Route 53 access tightly:

• Require MFA for any operation that modifies DNS records: route53:ChangeResourceRecordSets
• Separate the role that manages DNS from application deployment roles
• Use IAM conditions to restrict which hosted zones a role can modify
• Alert on CloudTrail events for ChangeResourceRecordSets in production zones

A CloudWatch alarm on ChangeResourceRecordSets for your production hosted zone is one of the highest-priority CloudTrail alarms you can create. An attacker with DNS modification capability can compromise your entire application. See our CloudTrail alerting guide for the setup.

Route 53 Health Checks

Route 53 health checks monitor your endpoints and automatically update DNS to fail over to healthy resources. From a security perspective, they're also useful for detecting when something goes wrong with your application infrastructure. Configure health checks for all critical endpoints:

resource "aws_route53_health_check" "app" {
  fqdn              = "app.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30

  tags = {
    Name = "production-health-check"
  }
}

Set up SNS notifications for health check status changes — an unexpected health check failure might indicate a DoS attack, infrastructure failure, or certificate issue.

Resolver DNS Firewall

Route 53 Resolver DNS Firewall lets you block DNS resolution for known malicious domains within your VPC. This provides defense-in-depth: even if an EC2 instance or Lambda function is compromised and tries to contact a C2 server, DNS Firewall can block the resolution.

AWS manages a list of known malicious domains that DNS Firewall can use. You can also add custom block lists. GuardDuty findings about unusual DNS activity can inform your DNS Firewall rules.

resource "aws_route53_resolver_firewall_rule_group" "main" {
  name = "malicious-domains"
}

resource "aws_route53_resolver_firewall_rule" "block_malware" {
  name                    = "block-malware-domains"
  rule_group_id           = aws_route53_resolver_firewall_rule_group.main.id
  priority                = 100
  action                  = "BLOCK"
  block_response          = "NXDOMAIN"
  firewall_domain_list_id = aws_route53_resolver_firewall_domain_list.malware.id
}

DNS Firewall is particularly valuable for preventing crypto mining (malicious instances phoning home), data exfiltration via DNS tunneling, and lateral movement within your VPC. See our guide on crypto mining detection for related patterns.

Private Hosted Zones

Route 53 private hosted zones resolve DNS only within specified VPCs. Use them for internal service discovery, internal-only endpoints, and split-horizon DNS (different resolution for internal vs. external requests). Security considerations:

• Never expose internal service names in public DNS — this reveals infrastructure details
• Ensure VPC associations are tightly controlled — a compromised VPC shouldn't be able to resolve your internal service names
• Audit VPC associations periodically to remove VPCs that should no longer have internal DNS access

CloudTrail Events to Watch

For Route 53 security monitoring, alert on these CloudTrail events:

• ChangeResourceRecordSets — DNS record changes, especially in production zones
• DeleteHostedZone — Entire zone deleted
• DisableHostedZoneDNSSEC — DNSSEC disabled
• AssociateVPCWithHostedZone — New VPC added to a private zone
• ChangeTagsForResource — Tag changes that might affect access control

FAQ

Should I enable DNSSEC for all my domains?

Yes, for any domain you own and care about. DNSSEC prevents DNS spoofing attacks and is increasingly required by enterprise and government customers. The operational overhead of enabling and maintaining DNSSEC through Route 53 is minimal.

How do I detect subdomain takeover at scale?

Tools like subjack, nuclei, and AWS Config custom rules can scan your DNS records for dangling CNAMEs. Run these checks periodically (monthly minimum) and integrate into your CI/CD pipeline to catch issues when infrastructure is decommissioned.

What's the risk of Route 53 query logging?

Query logs may contain sensitive domain lookups from your users (e.g., lookups to internal service names that reveal architecture). Store logs in a restricted S3 bucket with encryption. For GDPR-sensitive workloads, consider the data minimization implications of logging all DNS queries.