DNS exfiltration ai agent attacks work by smuggling stolen data inside DNS queries: an agent encodes secrets into subdomain labels (for example c2VjcmV0.attacker.example) and the resolver dutifully forwards them to an attacker-controlled authoritative server. Because most egress controls never inspect port 53, this channel bypasses HTTPS allowlists entirely. Blocking it requires resolving and policing DNS at the egress boundary.
Why DNS is the agent exfil channel nobody monitors
Security teams pour effort into HTTP allowlists, TLS interception, and prompt classifiers, but almost nobody inspects the resolver path. That gap is exactly what makes DNS attractive for an autonomous agent that has been coaxed (by indirect prompt injection, a poisoned tool response, or a compromised dependency) into leaking data. The agent does not need an open outbound HTTP route. It only needs to trigger name resolution, and name resolution almost always works.
The mechanics are simple and reliable:
- Encoding: The agent base32 or base64 encodes a secret, chunks it into labels under 63 bytes, and prepends them to a domain it controls.
- Transmission: Each lookup like
chunk1.chunk2.exfil.attacker.exampletravels through the local resolver, corporate DNS, and out to the attacker authoritative nameserver. - Reassembly: The attacker logs every incoming query and stitches the labels back into the original payload.
No listening HTTP server is required on the client side, no suspicious outbound TLS session appears in your proxy logs, and the queries look like ordinary (if oddly long) DNS traffic. That is why dns tunneling llm traffic slips past controls that were never designed to read the resolver path.
How dns tunneling llm traffic evades common controls
Consider a typical agent stack: a LangChain or MCP-based agent runs in a container, tool calls go out over HTTPS, and a proxy enforces a domain allowlist. That posture stops an agent from POSTing secrets to pastebin, but it does nothing about resolution. Here is what each layer misses.
| Control | What it inspects | Why DNS exfil evades it |
|---|---|---|
| Prompt classifier | Model input and output text | The encoded query is generated during tool execution, never in visible model output. |
| HTTP egress allowlist | Outbound HTTP/HTTPS hostnames | DNS resolution happens before and outside the HTTP layer. |
| TLS interception proxy | Decrypted HTTPS payloads | DNS over UDP/53 is not TLS and is not routed through the proxy. |
| Service mesh egress rules | L4 host and port to known services | Port 53 to the cluster resolver is almost always allowed by default. |
The uncomfortable conclusion: your agent can hold a database credential, get instructed by poisoned retrieved content to leak it, and quietly drip it out over hundreds of DNS lookups while every dashboard stays green.
How to block dns exfiltration agent behavior at egress
The reliable fix is to treat DNS as a first-class egress surface and apply the same default-deny discipline you already apply to HTTP. Agent G does this at the proxy boundary, resolving and policing name lookups instead of blindly forwarding them. Here is the enforcement model, step by step.
- Force all resolution through the proxy. Block direct UDP/TCP 53 from agent workloads to any resolver except the Agent G egress path. If the agent cannot reach an arbitrary resolver, it cannot open a private tunnel.
- Apply a resolution allowlist. Only names that map to approved destinations (your model provider, sanctioned APIs, approved MCP servers) resolve successfully. Everything else is denied by default, the same posture described in our default-deny egress guide.
- Score query entropy and structure. Flag long, high-entropy, frequently changing subdomain labels under a single parent domain, the signature of encoded payloads rather than legitimate hostnames.
- Rate limit per agent identity. A burst of hundreds of unique lookups to one parent zone in seconds is exfiltration behavior, not browsing. Throttle or block it and raise an alert.
- Block known tunneling patterns. Deny
TXTandNULLrecord abuse, oversized label chains, and resolution to newly seen authoritative nameservers that fall outside policy. - Log every decision out of band. Each allowed or denied query becomes a signed egress record, so an investigator can later prove exactly what the agent tried to resolve and when.
What legitimate agents lose (almost nothing)
A common objection: will policing DNS break normal tool calls? In practice, a well-scoped agent resolves a small, stable set of hostnames: its LLM provider, a handful of internal APIs, and its approved MCP servers. Those names sit on the allowlist and resolve instantly. The traffic that gets blocked is precisely the traffic a healthy agent never generates: rapid-fire lookups of random-looking subdomains under an unfamiliar parent zone. Because Agent G enforces at the egress boundary rather than inside the agent process, a compromised or jailbroken agent cannot code its way around the control. The policy lives outside the agent trust boundary.
DNS command and control ai risk, not just exfil
The same channel runs in reverse. An attacker can stage dns command and control ai instructions in TXT records that the agent periodically resolves and parses, turning name resolution into a covert command bus. Default-deny resolution closes this too: if the agent can only resolve approved names, it cannot poll an attacker zone for instructions. Pair that with tool-argument inspection and you remove both the inbound command path and the outbound data path in one enforcement layer.
Frequently Asked Questions
Can I just block port 53 on agent workloads?
Blocking arbitrary port 53 is a good start, but agents still need name resolution to function. The right move is to force all DNS through a controlled egress path that resolves against an allowlist, scores query entropy, and logs every lookup, rather than a blanket block that breaks legitimate tool calls.
Does TLS interception stop DNS exfiltration?
No. TLS interception decrypts HTTPS payloads, but classic DNS runs over UDP/53 and never touches your TLS proxy. Even DNS over HTTPS needs separate policy. You must inspect and police the resolution path itself to catch a dns exfiltration ai agent tunneling data through subdomain labels.
How do I detect DNS tunneling versus normal lookups?
Look for high-entropy subdomain labels, an unusually high count of unique names under one parent zone, rapid query bursts tied to a single agent identity, and resolution to newly seen authoritative nameservers. Agent G scores these signals at egress and denies or throttles matching traffic while logging the decision.
Will this slow down my agents?
No meaningfully. Allowlisted names resolve normally through the proxy, and enforcement adds negligible overhead. The only traffic that pays a penalty is anomalous, high-volume resolution that a legitimate agent would never generate in the first place.
DNS exfiltration ai agent attacks succeed because the resolver path is the one egress surface most stacks leave wide open. Agent G closes it with default-deny resolution, entropy scoring, per-identity rate limits, and signed logging, all enforced outside the agent trust boundary. Learn more about our approach on the Agent G homepage, see how tool inspection fits together in the MCP gateway, and read how we block destructive agent actions and enforce a default-deny egress allowlist. Ready to close the DNS gap? Request access to the Agent G private beta.