DNS Security

DNS Security on AWS covers protecting your DNS infrastructure and using DNS as a security control point. DNS deserves both roles: it is a dependency every workload shares, an attack target in its own right, and one of the most abused exfiltration channels, because almost every environment lets DNS queries out even when everything else is locked down.

Route 53 Security

• DNSSEC Signing: cryptographic signing of DNS records to prevent spoofing and cache poisoning
• Private Hosted Zones: DNS resolution only within VPCs, not publicly accessible
• Route 53 Resolver: DNS resolution between VPCs and on-premises networks

Route 53 Resolver DNS Firewall

• Filter outbound DNS queries from your VPCs
• Block resolution of known malicious domains
• Prevent DNS-based data exfiltration (DNS tunneling)
• Use AWS-managed domain lists (malware, botnet C&C) or custom lists

Best Practices

• Enable DNSSEC for public hosted zones
• Use DNS Firewall in all VPCs to block malicious domains
• Log DNS queries with Route 53 Resolver Query Logging
• Monitor GuardDuty DNS findings for C&C communication

Why DNS Exfiltration Works

DNS tunneling encodes stolen data into the labels of DNS queries: a compromised process asks for something like a long hex string prefixed to attacker-domain.example, and the attacker's authoritative name server receives and decodes the query. No connection to a suspicious IP ever appears in your flow logs, because the traffic rides through your own resolver. This is why query logging and DNS Firewall matter: the resolver is the one chokepoint that sees every lookup. Sudden bursts of long, high-entropy, never-repeated subdomains toward one domain are the signature to alert on, and GuardDuty includes detections for exactly this pattern on EC2.

How It Goes Wrong in Practice

Beyond tunneling, the most common self-inflicted DNS wound is the dangling record, the setup for subdomain takeover. A team spins up an S3 static site, an ELB, or a third-party service, points a CNAME like app.example.com at it, then later deletes the resource but not the DNS record. The name now resolves to infrastructure nobody owns, and on services where names are claimable, an attacker registers the abandoned target and is suddenly serving content, and receiving cookies, under your domain. The defense is boring lifecycle discipline: treat DNS records as part of the resource being decommissioned, audit zones for records pointing at resources that no longer exist, and prefer alias records to AWS resources you actually control. The second recurring gap is enabling DNSSEC signing in Route 53 but never completing the chain of trust by publishing the DS record at the parent zone; the zone signs its answers, but no resolver validates them, so the protection is cosmetic.

A Practical Check: Verifying DNSSEC Status

To confirm whether a public hosted zone is actually signing, and with which keys:

aws route53 get-dnssec --hosted-zone-id Z1234567890ABC

The response contains a Status structure whose ServeSignature field reads SIGNING when DNSSEC signing is active (other values include NOT_SIGNING, DELETING, ACTION_NEEDED, and INTERNAL_FAILURE), plus the list of key-signing keys with their status, their KMS key ARN, and the DS record you must publish at the parent registrar to complete the chain of trust. ACTION_NEEDED on a KSK usually means a KMS permission problem and deserves an alarm, since a zone that fails to sign can become unresolvable for validating resolvers.

Frequently Asked Questions

Does DNSSEC encrypt my DNS traffic?

No. DNSSEC provides authentication and integrity: resolvers can verify that an answer really came from the zone owner and was not tampered with in transit. The queries and responses remain readable. Confidentiality of DNS traffic is a separate concern addressed by transports like DNS over HTTPS or TLS, which is a client-to-resolver matter, not a Route 53 zone setting.

What is the difference between DNS Firewall and Network Firewall for domain filtering?

Route 53 Resolver DNS Firewall filters at the resolution step: it decides which names your VPC may look up, and it only sees queries that go through the Route 53 Resolver. AWS Network Firewall inspects packets on the wire and can also filter by domain via TLS SNI, catching clients that bypass your resolver by talking to external DNS servers directly. Defense in depth uses both: block lookups at the resolver, and block port 53 traffic to anything except the resolver at the network layer.

Are private hosted zones reachable from the internet?

No. A private hosted zone answers queries only from the VPCs you associate with it. The classic mistake is putting internal hostnames into a public zone instead, which leaks your internal architecture to anyone who enumerates the zone.