Cloudflare just shipped Internal DNS for private networks — here's what it means for agent infrastructure
Cloudflare Internal DNS brings authoritative and recursive DNS for private networks to the same global network that runs Zero Trust. For agentic systems that coordinate across VPCs, it's the missing piece.
Cloudflare shipped Internal DNS to general availability yesterday. Authoritative and recursive DNS for private networks, running on the same global network that handles Zero Trust and public DNS.
This matters if you're running agentic systems that span multiple VPCs, hybrid cloud setups, or any infrastructure where agents need to coordinate across network boundaries without exposing endpoints to the public internet.
What Internal DNS actually does
Internal DNS lets you run private DNS zones on Cloudflare's network. You define records for internal services — databases, APIs, agent backends — and those records resolve only for devices authenticated through Cloudflare Zero Trust.
The resolver is recursive, so it can forward queries to on-prem DNS servers or other private resolvers. The authoritative side lets you define .internal or custom TLDs that exist nowhere else. Both run on Cloudflare's edge, not in your VPC.
For agentic systems, this means you can give agents stable DNS names for internal tools without hardcoding IPs or managing split-horizon DNS yourself. An agent running in AWS us-east-1 can call crm.internal and hit the same service as an agent in GCP europe-west1, routed through Cloudflare's network with Zero Trust policies enforced.
Why private DNS has been a coordination tax
Most multi-region agent setups use one of three patterns:
- Hardcoded IPs in environment variables — brittle, requires redeployment to change backends
- Public DNS with IP allowlists — exposes internal services to scanning, requires firewall management
- VPN or private link between clouds — high latency, complex routing, expensive
All three add friction. Agents that need to coordinate across environments either carry hardcoded topology or require a service mesh. Internal DNS eliminates the hardcoded part — agents can resolve names the same way whether they're local or remote, and Cloudflare enforces authentication at the DNS layer.
We're testing this with Best Limo NY's dispatch system. They have an agent cluster in us-east-1 that writes to a PostgreSQL instance in us-west-2, plus a voice agent pool in europe-west1 that queries the same database for real-time availability. Before Internal DNS, we used a Tailscale mesh to route traffic between regions. It worked, but added 40–60ms of latency and required maintaining Tailscale configs on every agent host.
With Internal DNS, we defined dispatch-db.internal pointing to the us-west-2 Postgres endpoint. The voice agents in Europe resolve that name through Cloudflare's resolver, which forwards the query through Zero Trust and returns the internal IP. Latency dropped by 25ms on average, and we removed the Tailscale dependency entirely.
The catch: you need Zero Trust already
Internal DNS is part of Cloudflare Zero Trust, not a standalone product. You need devices enrolled in WARP or Gateway to resolve internal zones. If you're not already using Zero Trust for device authentication, you're adding that whole setup to get DNS.
For SMBs running agentic systems, that's often fine — most are already using some form of VPN or identity proxy. Cloudflare Zero Trust replaces both. For enterprises with established Okta/Zscaler stacks, it's a heavier lift.
The pricing is per seat for users, per GB for Gateway traffic. Internal DNS itself doesn't have a separate line item — it's included once you're paying for Zero Trust. For agent-only deployments (no human users), you pay for Gateway traffic, which starts at $7/month for the first 3 GB and scales from there.
What this unlocks for agent coordination
The real win is removing a whole class of networking configuration from agent deployments. Before, spinning up a new agent cluster in a new region meant updating DNS records, configuring VPN routes, or deploying a new service mesh sidecar. With Internal DNS, you define the name once and agents in any authenticated network can resolve it.
This also helps with zero-downtime migrations. We're moving Bergsify's call routing backend from Heroku to Fly.io next month. With Internal DNS, we can define routing.internal pointing to the old Heroku dyno, then update the record to point to the new Fly machine once it's validated. Agents keep calling routing.internal with no code changes.
Cloudflare also ships health checks for Internal DNS records, so you can route traffic away from a backend if it stops responding. That's table stakes for public DNS but rare for private zones unless you're running a full service mesh.
Why we're using it
Our agent deployments are split between AWS (us-east-1 for most clients), Fly.io (for voice agents close to Twilio's edge), and occasional GCP instances for clients with existing Google infra. Coordinating those three without a mesh has meant either hardcoding endpoints or running a separate Consul cluster just for service discovery.
Internal DNS gives us the service discovery part without the Consul overhead. Agents resolve names, Cloudflare enforces authentication, and we get global routing without managing it ourselves. It's not zero config — you still define the zones and records — but it's less config than the alternatives.
For anyone running agentic systems across multiple clouds or regions, Internal DNS is worth testing. It's not magic, but it removes one layer of networking glue that usually requires custom tooling or a service mesh.