The DNS Attack Your AI Platform Ignores

The Gap Nobody Talks About

Your AI agent platform validates URLs before making HTTP requests. It checks the hostname against a blocklist. It verifies the destination is not an internal service. It confirms the request is allowed by the egress policy. The URL passes validation. The request proceeds.

Between validation and the actual TCP connection, DNS resolution happens. The hostname is resolved to an IP address. The connection is made to that IP address.

What if the IP address changed between validation and connection?

This is DNS rebinding. It is a well-documented attack class. It has been exploited against web browsers, server-side applications, and cloud infrastructure for over a decade. And almost no AI agent platform defends against it.

Hostnames are not security boundaries. IP addresses are. Any defense that validates hostnames but connects to IPs has a gap between what it checked and what it used.

How DNS Rebinding Works

The attack is straightforward:

Step 1. The attacker registers a domain they control. They set up a DNS server for that domain with a very short TTL (time-to-live) on the A record. The record initially points to a legitimate public IP address.

Step 2. The agent (or a prompt injection) triggers a request to the attacker's domain. The platform validates the URL. The hostname is not on any blocklist. The domain resolves to a public IP. Validation passes.

Step 3. The DNS TTL expires. This can happen in as little as one second.

Step 4. The attacker's DNS server changes the A record to point to a private IP address: 127.0.0.1 (localhost), 169.254.169.254 (cloud metadata endpoint), 10.0.0.5 (internal database), or any other internal address.

Step 5. The HTTP client resolves the hostname again (the cached entry expired) and connects to the new IP. The request that was validated against a public hostname is now hitting your internal infrastructure.

The platform validated the hostname. The hostname was fine. But the IP the hostname resolved to at connection time was different from the IP it resolved to at validation time. The validation was correct at the time it ran. It was wrong by the time the connection was made.

TOCTOU: The Fundamental Vulnerability

This is a Time-of-Check-to-Time-of-Use vulnerability. The check (URL validation) and the use (TCP connection) are two separate operations with a time gap between them. Anything that can change between the check and the use invalidates the check.

DNS records can change between the check and the use. That is the entire point of TTL. DNS is designed to allow records to change. The attacker is not exploiting a bug in DNS. They are using DNS exactly as designed, with a short TTL that causes re-resolution between validation and connection.

Most platforms attempt to solve this with hostname-level checks:

Hostname blocklist. Block known internal names like "localhost," database hostnames, cache hostnames, metadata endpoints. This works for known names. It does not work for arbitrary attacker-controlled domains that resolve to private IPs. You cannot blocklist every possible hostname. There are infinite hostnames. There are finite private IP ranges.

DNS pre-resolution. Resolve the hostname before validation, check the resulting IP, then allow the request. Better. But still vulnerable. The HTTP client may re-resolve the hostname before connecting (DNS cache expiry, connection pooling, retry logic). The IP you checked is not necessarily the IP the client connects to.

Neither approach eliminates the gap. They narrow it. But a narrow gap is still a gap. DNS rebinding does not need a wide window. It needs any window.

The Fix: Atomic Resolve-Validate-Connect

HeartBeatAgents eliminates the TOCTOU gap by performing DNS resolution, IP validation, and TCP connection in one atomic operation at the network stack level.

Here is how it works:

Step 1: Resolve once. When the HTTP client is about to open a TCP connection, the platform intercepts the operation at the lowest level of the network stack, before the socket is created. It performs DNS resolution and captures every IP address the hostname resolves to. (Most hostnames resolve to multiple IPs for load balancing and redundancy.)

Step 2: Validate every IP. Every resolved IP is checked against the full range of private, loopback, link-local, and reserved address spaces. If any resolved IP is private, the entire request is blocked. Not just the private IP. All of them. If a hostname resolves to three public IPs and one private IP, the request is denied.

Step 3: Connect using the same resolution. The TCP connection proceeds using the same DNS resolution from step 1. The operating system's DNS cache ensures that the IPs resolved in step 1 are the same ones used for the connection. There is no second resolution. There is no gap.

The key insight: resolution, validation, and connection happen in the same operation, at the same layer, using the same DNS data. The IPs that were validated are the IPs that are connected to. There is no time gap. There is no cache expiry between steps. There is no opportunity for the attacker to change the DNS record between validation and connection.

The IP we validate IS the IP we connect to. Zero gap between check and use.

What Gets Blocked

The IP validation covers every private and reserved address range defined by the IETF:

RFC 1918 private ranges. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. These cover Docker container networks, VPNs, home and office networks. Any hostname resolving to these ranges is blocked.

Loopback. 127.0.0.0/8 and the IPv6 equivalent. An attacker's domain resolving to 127.0.0.1 would hit services running on the agent's own host. Blocked.

Link-local. 169.254.0.0/16. This is the range used by cloud metadata endpoints (AWS, GCP, Azure all expose instance metadata at 169.254.169.254). Accessing the metadata endpoint can expose cloud credentials, instance identity tokens, and network configuration. Blocked.

IPv6 private and loopback. fc00::/7 (unique local addresses) and ::1/128 (loopback). Same protection as IPv4, extended to IPv6. Blocked.

Reserved ranges. 0.0.0.0/8 (current network), 100.64.0.0/10 (carrier-grade NAT), 198.18.0.0/15 (benchmarking). Edge cases that should never be connection targets for agent requests. Blocked.

Unparseable addresses. If the IP address cannot be parsed, it is treated as private. Fail closed. An address format the system does not recognize is not given the benefit of the doubt.

Punycode and IDN Homograph Attacks

DNS rebinding is not the only way to abuse hostname resolution. Internationalized Domain Names (IDN) introduce a visual attack vector.

Cyrillic "a" (U+0430) is visually identical to Latin "a" (U+0061) in most fonts. An attacker can register a domain where one or more characters are replaced with lookalikes from a different Unicode script. To a human reading the URL, it looks identical to the legitimate domain. To DNS, it is a completely different hostname resolving to a completely different server.

HeartBeatAgents normalizes every hostname through IDNA encoding before any validation occurs. The hostname is converted to its ASCII-compatible Punycode form. If the Punycode form differs from the original and the original contains non-ASCII characters, the request is blocked.

This catches:

Single-character substitution. Replacing one Latin character with a visually identical character from Cyrillic, Greek, or other scripts.

Mixed-script domains. Domains that combine characters from multiple Unicode scripts to create a hostname that looks legitimate but resolves elsewhere.

Homograph bypass of the approved host list. An attacker cannot create a Unicode variant of an approved API host and use it to bypass egress policy validation. The normalization catches the mismatch before the hostname reaches the policy engine.

Two Layers, Complete Coverage

The full hostname-to-IP defense operates as two layers:

Layer 1: Hostname blocklist. Fast, string-level checks. Catches known internal service names, cloud metadata endpoints, and internal network suffixes. Operates before any DNS resolution occurs. Catches the obvious cases instantly.

Layer 2: Connection-time IP validation. Operates at the network stack. Resolves the hostname, validates every resulting IP, and connects using the same resolution. Catches everything Layer 1 misses: arbitrary domains resolving to private IPs, DNS rebinding attacks, short-TTL record flipping, and any hostname that was not on the blocklist but resolves to a dangerous destination.

Layer 1 is fast. Layer 2 is definitive. Together:

Known internal service names are caught by Layer 1 without a DNS query. Arbitrary attacker domains resolving to private IPs are caught by Layer 2 at connection time. DNS rebinding (record changes between validation and connection) is eliminated by Layer 2's atomic resolve-validate-connect. Punycode homographs are caught by Layer 1's IDNA normalization.

No single layer covers every attack vector. Both together cover the full surface.

Why This Matters for AI Agents Specifically

DNS rebinding is a known attack class in web security. It has been studied for over a decade. Why is it specifically dangerous for AI agent platforms?

Agents accept arbitrary input. A web browser's same-origin policy limits DNS rebinding damage. An AI agent has no same-origin policy. It makes HTTP requests based on instructions from the LLM, which processes input from users, external data sources, and tool results. Any of those inputs can contain a malicious URL. The agent does not distinguish between a legitimate API endpoint and an attacker's rebinding domain.

Agents carry credentials. When an agent makes an HTTP request, it often carries an OAuth token in the Authorization header. A DNS rebinding attack redirects that authenticated request to internal infrastructure. The internal service receives a request with a valid external OAuth token. Depending on the service, this could grant unauthorized access.

Agents make POST requests. DNS rebinding in a browser is mostly limited to GET requests (due to CORS preflight restrictions). An AI agent has no browser. No CORS. No preflight. It makes POST, PUT, PATCH, and DELETE requests directly. A rebinding attack against an agent can trigger write operations against internal services.

Agents operate autonomously. A browser-based DNS rebinding attack requires the user to visit a malicious page. An agent-based attack requires only that the agent process a piece of text containing a URL. The attack surface is the agent's entire input stream: user messages, tool results, web scraping results, email content, and anything else the agent reasons about.

The combination of arbitrary input, carried credentials, unrestricted HTTP methods, and autonomous operation makes AI agents a higher-value target for DNS rebinding than traditional web applications. The defense must be proportionally stronger.

The Question to Ask

If you are evaluating AI agent platforms, ask this question about DNS rebinding:

"When the agent makes an HTTP request, what happens between URL validation and the TCP connection?"

If the answer involves two separate operations (validate hostname, then connect), there is a TOCTOU gap. DNS rebinding can exploit it.

If the answer is "we resolve, validate every IP, and connect in one atomic operation at the network stack," the gap does not exist. The IPs that were validated are the IPs that are connected to. DNS rebinding has no window to exploit.

Most platforms do not have an answer to this question because they have not considered it. That is the most dangerous answer of all.