Cloudflare Private Origins Turns DNS Into a Network Boundary

Put a proxied record in Cloudflare’s DNS pointing at 10.0.4.21 and the hostname answers from the public internet. No tunnel daemon. No port forward. No security group hole into your VPC. That is the part of Cloudflare’s Private Origins GA worth arguing about.

The feature went GA this week after a closed beta that started in June. Cloudflare detects RFC 1918 addresses in proxied records automatically. From there it serves them through Cloudflare One connectivity, which means WAF, bot management, rate limiting, caching, and Workers sit in front of the origin. Spectrum covers private TCP and UDP. Workers get the same path.

The press framing is convenience. Boring. The real change is that a rule I have built firewall policy on for fifteen years just became false.

For years the rule was: if it answers a public DNS name, it is reachable from the public internet. That stops being true here. Any resolver-based inventory you maintain, and any “exposed” boolean you compute from DNS, now reports wrong answers.

What the connector was actually buying you

Tunnel and Private Network setups always had a cost the marketing skipped. With cloudflared, someone has to ship an agent into that private network and keep it alive. With WAN and Mesh, you get requirement creep: a Private Origins entitlement, Unified Routing on top of Cloudflare One, and return routes Cloudflare documents precisely as 100.64.0.0/12 and 2606:4700:cf1:5000::/64. Miss the return path and the service “works” in a way that only fails under load, which is a fun afternoon.

Notice also what the fixed addresses buy an attacker. If you open a WAN path to Cloudflare, a source ACL pinned to those ranges is now the entire boundary. You have moved the trust anchor from “our IP allowlist” to “a route table entry we may have configured wrong.” Fine, if you audit it. Not fine if you set it once in a maintenance window in 2024 and forgot.

MCP servers are the reason this shipped

Cloudflare’s own write-up lists internal APIs, AI agent backends, MCP servers and operational tooling as the services customers needed exposed but had not hardened. I watched exactly that gap open this year. People stood up MCP servers against internal databases over a weekend, found the tool useful, and then realized the endpoint has no authentication story beyond whatever the SDK defaulted to. Streamable HTTP with a bearer token someone pasted into a config file.

The rate limiting and WAF in front of that is worth more than the network plumbing. A private origin with Cloudflare’s edge in front can be capped, challenged, and logged. The same process on a raw inbound port gets neither. There is a caveat: it is only as private as the DNS record. Once a hostname resolves from the internet, the origin is reachable through Cloudflare, and the security lives entirely in your WAF and Access policies. An unprotected record behind Private Origins is now a public endpoint with extra steps, and I have already seen that mistake in the wild.

Where I would still pick a tunnel

Private-to-private is not supported yet. Beta targeted for early 2027. That means the common case, a service in network A calling an app in network B, still needs the classic mesh or a connector, and the GA announcement does not explain whether the entitlement costs anything on top of an Enterprise contract. Regulatory auditors will want to know whether Cloudflare One now terminates TLS for internal data that used to stay inside the perimeter. For an internal admin panel holding patient or cardholder data, I would want that answer in writing before the DNS record ships.

Competitors are in the same space. CloudFront VPC Origins and Azure Front Door with Private Link exist. What Cloudflare adds is zero inbound ports and no connector binary in the network, which removes the two operational items that break most often.

Run this before you trust any inventory that scans for exposed services.

dig +short api.internal.example.com @1.1.1.1 | head -3
# a 104.x or 172.6x address means the name is public,
# whatever the upstream address behind it looks like

Anything that returns a Cloudflare edge address while the origin sits on RFC 1918 will pass your scanner and fail your assumption. The next thing I would test is whether an Access policy on such a hostname logs the internal upstream address in the request log by default, because that log is now a map of your private network and it should not be shared with anyone who merely has dashboard read access.