DNS Tunneling

DNS normally translates names into records that applications use to locate services. DNS tunneling instead encodes other information into query names or response data. A client might send queries containing encoded data beneath a domain controlled by an attacker. Recursive resolvers forward those queries toward the domain's authoritative servers, where the attacker can recover the information. Responses can carry instructions or additional data back to the client. The workload does not necessarily need a direct connection to the attacker's server; access to a recursive resolver that can resolve external domains may be enough.

In cloud environments, this matters because DNS often remains available even when ordinary internet egress is restricted. For example, a compromised virtual machine could repeatedly request long, changing subdomains beneath an unfamiliar parent domain. Those names might encode stolen information, while the responses provide commands. Tunneling can use several DNS record types; it is not limited to TXT records, UDP, or unusually large responses. DNS tunneling is also distinct from DNS spoofing, cache poisoning, and ordinary malicious-domain lookups.

The most useful detection source is a DNS query log that records queried names, query types, response codes, timestamps, and client identity where available. In AWS, configure Amazon Route 53 Resolver query logging for the relevant VPCs and send the records to an appropriate supported destination. Check the actual resolution path: workloads using custom DNS servers or external encrypted resolvers can bypass that visibility. Resolver query logging also does not record queries answered from the Resolver cache, so it should not be treated as a complete application-level request counter. Public hosted-zone query logs are not a substitute for visibility into workload DNS activity.

VPC Flow Logs provide complementary connection metadata, such as addresses, ports, packet counts, and byte counts, but do not contain queried domain names or DNS payloads. Importantly, they do not capture traffic to the Amazon-provided DNS server. They can help investigate connections to custom DNS servers or external resolvers when those flows are captured. Transit gateway flow logs provide similar network-level context for traffic traversing a transit gateway; they do not inspect DNS content and cannot observe traffic that never crosses that gateway. Choosing a log source therefore requires understanding both the suspected attack and the network path.

Practical analytics examine combinations of signals: unusually long or high-entropy labels, many unique subdomains under one parent domain, repeated queries at regular intervals, unexpected record types, and abnormal response-code patterns. None is conclusive alone. Content-delivery systems, security products, and service-discovery mechanisms can generate unusual-looking DNS legitimately. Baseline behavior by workload, correlate suspicious names with endpoint processes and network activity, and retain enough history to identify low-volume tunnels.

Prevention combines controlled DNS resolution with domain filtering and egress restrictions. Require approved resolvers, restrict direct external DNS where feasible, and account for DNS over HTTPS and DNS over TLS. In AWS, security groups and network ACLs cannot filter traffic to the Amazon-provided DNS server; Route 53 Resolver DNS Firewall provides DNS-layer filtering for that path. Known-domain blocking alone is insufficient when an attacker can register new domains. Strict allowlists can reduce exposure but require maintenance and can disrupt legitimate dependencies. During an investigation, preserve relevant logs, isolate the affected workload, and address the compromise rather than merely blocking one domain.