Recursive DNS resolvers can turn a routine name-lookup service into a quiet exfiltration relay, carrying encoded data through infrastructure most organizations allow by default.
DNS is trusted because it is necessary. Workstations need it. Servers need it. Cloud workloads need it. Security tools depend on it. Blocking DNS outright breaks the network, so many environments treat resolver traffic as background noise: high-volume, low-interest, and too operationally sensitive to inspect aggressively.
That trust creates an opening. An attacker who can cause a compromised host to issue DNS queries can move data outward without opening an obvious TCP session to an unknown server, uploading a file, or triggering conventional data-loss prevention controls.
The recursive resolver becomes the middleman. It accepts the query, performs the lookup, and forwards the request through the DNS hierarchy until it reaches an authoritative server controlled by the attacker.
The data is not in the answer. It is often in the question.
How Recursive Resolution Becomes an Exfiltration Channel
A recursive resolver accepts a query from a client, finds the answer by querying other DNS servers, caches the result, and returns the response.
In a typical enterprise, endpoints send DNS queries to internal resolvers. Those resolvers then communicate with root servers, top-level domain servers, and authoritative name servers.
Attackers abuse that chain by registering or compromising a domain they control, then causing infected systems to generate lookups under that domain. Sensitive data is encoded into subdomain labels:
encoded-data.chunk-id.session-id.attacker-domain.example
The endpoint asks its configured recursive resolver to resolve the name. The resolver does what it was built to do: it forwards the query. Eventually, the full query name reaches the attacker’s authoritative DNS server, where the encoded labels can be logged and reconstructed.
No direct connection from the victim host to the attacker’s web server is required. From the endpoint’s perspective, it only contacted a DNS resolver it may already be allowed to use. From the attacker’s perspective, the inbound query may appear to come from the victim organization’s resolver, a public resolver, or a chain of forwarding resolvers rather than the original machine.
That separation is what makes recursive resolvers useful for stealth.
Why DNS Is Attractive for Data Theft
DNS has several properties that make it appealing to attackers.
First, it is almost always permitted. Even restrictive networks usually allow DNS traffic to approved resolvers. Some environments also allow outbound UDP/53 or TCP/53 to the internet, either by design or by accident.
Second, DNS is noisy. Large organizations generate enormous volumes of lookups from browsers, software updaters, telemetry agents, package managers, endpoint protection tools, and cloud services. Malicious queries can hide among millions of benign requests.
Third, DNS names are flexible. Each label can contain up to 63 octets, and a full domain name can reach 253 octets in presentation form. That creates room to embed chunks of encoded data. Attackers often use encodings that survive DNS label restrictions, such as base32-like alphabets or custom character sets.
Fourth, DNS traffic is frequently logged incompletely. Many teams log firewall flows but not full query names. Others keep resolver logs for only a short period because the volume is high. Without the query name, exfiltration through DNS is difficult to reconstruct.
Fifth, recursive infrastructure can obscure attribution. The attacker-controlled authoritative server may only see the recursive resolver’s source IP. If the victim uses a public resolver, the attacker may see traffic from shared infrastructure used by many customers.
The Role of Caching
Caching is central to DNS performance, but attackers need to work around it.
If many clients request the same name, a recursive resolver can answer from cache and avoid contacting the authoritative server again until the time-to-live expires. For exfiltration, that is a problem: the attacker needs each payload-bearing query to reach the authoritative server.
The usual answer is uniqueness. Each query name contains a fresh chunk identifier, session value, counter, nonce, or encoded data block that prevents cache hits. That can produce a recognizable pattern: many unique subdomains under a single parent domain, often with low or no meaningful repetition.
For defenders, this is valuable. High-cardinality subdomain activity is one of the strongest indicators of DNS-based exfiltration. A normal domain may receive repeated queries for names such as www, api, cdn, or region-specific hosts. An exfiltration domain may receive thousands of never-before-seen labels that look random.
Caching can also create blind spots. If a resolver answers repeated control queries from cache, an endpoint’s DNS activity may not be visible upstream. Local resolver logs remain essential.
Recursive Resolvers as Stealth Multipliers
The recursive resolver is not merely a passive transport. Its placement can make the attack harder to see.Enterprise Recursive Resolvers
In many organizations, endpoints are forced to use internal resolvers. That sounds safer, and it usually is. It gives defenders a central inspection point. But if those resolvers are not monitored for unusual query patterns, they can become sanctioned exfiltration relays.
From a firewall perspective, only the resolver is communicating externally. The compromised workstation may never make a direct outbound connection to the attacker’s infrastructure.
- Public Recursive Resolvers Public resolvers such as Google Public DNS, Cloudflare DNS, Quad9, and ISP-provided resolvers are widely used. Attackers may configure malware to use public resolvers to bypass internal visibility, especially if outbound DNS is not restricted.
Encrypted DNS adds another layer. DNS over HTTPS and DNS over TLS can prevent middleboxes from inspecting query names unless traffic is forced through managed resolvers or intercepted under enterprise policy. A compromised host using an unmanaged DoH endpoint may blend DNS exfiltration with ordinary HTTPS traffic.
- Open Recursive Resolvers Open recursive resolvers exposed to the internet remain a security problem. They are often discussed in the context of amplification attacks, but they can also help obscure traffic paths. An attacker can route queries through third-party recursive servers so the authoritative side sees resolver addresses unrelated to the originating victim.
Organizations should not run open resolvers unless they are intentionally operating public DNS infrastructure with abuse controls, rate limits, and monitoring.
Common Exfiltration Patterns
DNS exfiltration tends to leave behavioral fingerprints.
A. Long, High-Entropy Query Names
Encoded payloads often look random:
mfrggzdfmztwq2lk.mjqxgzjanrxw4z3f.example.net
Benign services also generate long names, especially content delivery networks, tracking systems, anti-abuse platforms, and cloud tools.
Entropy alone is not enough. It becomes more useful when combined with other signals: unusual parent domain, repeated long labels, high uniqueness, and consistent query timing.
B. Many NXDOMAIN Responses
Some exfiltration schemes do not require valid DNS answers. The attacker only needs to receive the query at the authoritative server. The response may be NXDOMAIN, NODATA, or a minimal record.
A high NXDOMAIN ratio from one host or toward one domain can indicate tunnelling or exfiltration. Care is needed, because broken software, typo-heavy browsing, and internal search suffix behaviour can also generate NXDOMAIN noise.
C. Low-Volume, Long-Duration Transfer
Not every DNS exfiltration attempt is loud. A patient attacker may send small chunks over hours or days, staying below simple rate thresholds. For example, a few hundred bytes per minute can be enough to leak API tokens, SSH keys, browser session cookies, configuration files, or selected database records.
This matters because DNS exfiltration is rarely used to move a 20 GB archive. It is more often used for high-value secrets that are small enough to hide.
D. TXT, NULL, and Unusual Record Types
Many attacks use ordinary A or AAAA queries because they look common. Others use TXT queries because TXT records can carry flexible data in responses, which is useful for command-and-control. Rare record types can stand out in enterprise telemetry.
A sudden increase in TXT queries from endpoints that normally issue mostly A, AAAA, CNAME, and SRV lookups deserves attention.
E. Detection Requires Resolver-Level Visibility
Firewall metadata alone is usually insufficient. Defenders need access to the DNS query name, query type, response code, client IP, resolver identity, timestamp, and ideally the resolved answer.
Strong DNS monitoring programs collect logs from recursive resolvers and normalize them into a searchable platform. Useful detections include:
• Unusually long fully qualified domain names
• Labels near the 63-octet limit
• High entropy labels under the same registered domain
• High volume of unique subdomains
• Excessive NXDOMAIN or NODATA responses
• Repeated queries to newly registered domains
• DNS traffic to external resolvers from non-resolver hosts
• DoH or DoT connections to unapproved providers
• Query patterns with fixed intervals or chunk-like counters
• Domains with low reputation, recent creation dates, or suspicious name server infrastructure
Passive DNS and threat intelligence can help, but local baselines matter more. A software build server, a browser-heavy workstation, and a domain controller will not have the same DNS profile.
F. Defensive Controls That Actually Reduce Risk
DNS exfiltration cannot be solved by one product. It requires control over where DNS goes, what gets logged, and how anomalies are handled.
G. Force DNS Through Managed Resolvers
Endpoints should not be able to send arbitrary DNS traffic to the internet. Block outbound UDP/53 and TCP/53 from all systems except approved recursive resolvers. Apply the same principle to IPv6, which is often forgotten.
For encrypted DNS, block or control unmanaged DoH and DoT. Browsers and operating systems increasingly support encrypted DNS directly, so policy enforcement must account for application-level behaviour, not only network ports.
H. Monitor the Resolvers, Not Just the Perimeter
Recursive resolvers are the best vantage point for detecting DNS exfiltration inside an enterprise. Enable detailed query logging where feasible. If full logging is too expensive, sample intelligently and preserve high-risk fields such as client address, query name, query type, and response code.
Retention matters. A week of DNS logs may not be enough for incident response, especially if the theft was slow.
I. Use Response Policy Zones and Domain Controls
Response Policy Zones can block or redirect queries for known malicious domains, newly observed domains, or categories that do not belong in the environment. This is useful against commodity tooling and known infrastructure.
Do not rely only on blocklists. Custom attacker domains may have no reputation history. Behavioral analytics are still required.
J. Close Open Recursion
Authoritative DNS servers should not provide recursion to the internet. Recursive DNS servers should restrict service to authorized networks. This is basic hygiene, but misconfigurations persist in cloud deployments, lab environments, mergers, and forgotten appliances.
K. Inspect Cloud and Container DNS Paths
Kubernetes clusters, serverless workloads, and cloud VPCs introduce additional resolver paths. A pod may query CoreDNS, which forwards to a cloud resolver, which then resolves externally. Logs may be split across layers.
Attackers who compromise cloud workloads can abuse these paths just as they would an endpoint resolver. Cloud DNS query logging should be enabled for sensitive accounts and production networks.
DNSSEC and QNAME Minimization Are Not Complete Answers
DNSSEC authenticates DNS data. It does not stop a compromised host from placing encoded data inside a query name. Signed zones can still receive maliciously crafted queries.
QNAME minimization reduces unnecessary disclosure to intermediate DNS servers by sending only the needed portion of a query during iterative resolution. That is good for privacy. It does not prevent the full query name from reaching the authoritative server responsible for the attacker-controlled domain. The payload still arrives where the attacker needs it.
Security controls must be aligned with the abuse pattern. DNS exfiltration abuses query generation and recursive forwarding, not merely spoofed responses or unsigned records.
Incident Response: What to Preserve
If DNS exfiltration is suspected, preserve resolver logs quickly. Also collect endpoint DNS cache data, process telemetry, EDR events, proxy logs, firewall flows, and any evidence of direct resolver configuration changes.
Key questions include:
• Which internal hosts generated the suspicious queries?
• Which parent domains received the highest number of unique subdomains?
• Did queries use approved resolvers or bypass controls?
• What query types and response codes were involved?
• Were the domains newly registered or hosted on unusual name servers?
• Do the encoded labels share chunk counters, timestamps, or session identifiers?
• What sensitive files, tokens, or credentials were accessible to the host?
Containment should include blocking the domain, isolating affected hosts, rotating exposed credentials, and reviewing adjacent systems. If the payload can be reconstructed from logs, treat it as confirmed data exposure.
The Practical Standard
DNS is not just plumbing. It is a data path with reach, trust, and weak inspection in many networks. Recursive resolvers are especially powerful because they sit between nearly every internal system and the public naming hierarchy.
The practical standard is straightforward: force DNS to approved resolvers, log enough to reconstruct abuse, detect high-entropy and high-cardinality query behaviour, control encrypted DNS, and treat resolver infrastructure as a security boundary. Attackers already understand that DNS is allowed almost everywhere. Defenders need to make that permission conditional, observable, and revocable.
Top comments (0)