Cloudflare pushed its Internal DNS service into general availability on July 20, and the pitch lands hard if you have ever chased a stale hosts file across three laptops: one platform for public and private DNS, one API, one audit trail, no appliance to rack. Then comes the fine print. The GA announcement says Internal DNS is “included with Cloudflare Gateway without any additional charge” — for Enterprise customers. If you run a five-person startup or a fifteen-person agency, the product making headlines this week is not actually aimed at you. That raises a more useful question than “how do I get it”: does a small team need internal DNS at all, and if so, what should it run in 2026?
The problem internal DNS solves — and how small teams fake it today
Internal DNS (Cloudflare’s post also calls it private DNS) answers name lookups for things that should never appear in public DNS: the staging database, the office NAS, the Grafana box, printer.corp.internal. Most small teams solve this with some mix of three duct-tape techniques. They hardcode IPs and pass them around in Slack. They edit /etc/hosts on each machine and hope everyone stays in sync. Or they lean on whatever mDNS/router-level naming their office gear happens to provide, which works until someone is on a VPN, on a different subnet, or working from a café.
The failure mode Cloudflare describes for big enterprises — split-horizon DNS setups where “when those systems drift, outages follow” — has a small-team equivalent. The drift just lives in humans instead of zone files. The new hire pings a decommissioned IP. The staging URL in the README points at a box that was re-addressed months ago. Nobody notices until a deploy script hangs. That is the actual pain internal DNS removes: names become the interface, and the mapping to addresses gets managed in exactly one place.
What GA actually shipped — and why the architecture matters even if you can’t buy it
It is worth understanding what Cloudflare built, because the design is a preview of how private naming is converging with zero-trust networking everywhere, not just at enterprise scale.
The service has two halves. The Gateway Resolver — the recursive engine Cloudflare launched in 2020, powered by the same infrastructure as 1.1.1.1 — evaluates policy on every query. Internal Authoritative DNS holds the private zone data, running on the authoritative platform Cloudflare has operated for over a decade. Administrators work with three objects, per the Internal DNS developer documentation: internal zones (the records for private resources), DNS views (which group zones into the resolution context a set of users or devices should see), and resolver policies (which route matching queries to a specific view). A query that matches a policy gets answered from the internal view; one that matches a block rule dies at the resolver; everything else falls through to public resolution on 1.1.1.1, so a single resolver serves both private and public names and clients never need to know the difference.
Two details stand out for anyone who has run BIND or a pile of dnsmasq configs. First, zone references let one shared zone appear in multiple views without copying records — the boring-sounding feature that kills split-horizon drift at the root. Second, every record change enters through the same DNS Records API whether it comes from the dashboard, Terraform, or a raw API call, and propagates across Cloudflare’s network in seconds rather than waiting out TTLs. One write path, one audit trail. That is the bar any internal naming setup should now be judged against.
The connectivity story is equally broad: the resolver takes traffic from the Cloudflare One Client (formerly WARP), DNS over HTTPS, DNS over TLS, plain port-53 DNS, PAC files, and Cloudflare WAN. On a Cloudflare WAN network, devices resolve internal names without running the client at all.
Three signals you actually need internal DNS
Strip away the enterprise packaging and the underlying need shows up in three concrete situations. If none of them describe your team, you can stop reading and keep your hosts file with a clear conscience.
1. The same name must answer differently inside and outside. If app.yourco.com should hit a private IP for employees and a public load balancer for everyone else, you have a split-horizon requirement. Faking this with hosts files is how you get the “works on my machine, 404s for the customer” class of incident. This is the clearest yes-you-need-it signal there is.
2. Services × contexts has outgrown human memory. Five services reached from one office can live in anyone’s head. Fifteen services reached from two offices, a VPN, and a cloud VPC cannot. Once the grid of what-resolves-from-where needs a spreadsheet, it needs a resolver instead.
3. You need to know who resolved what. The moment a compliance framework, a security review, or an incident post-mortem asks for DNS query logs on internal lookups, ad-hoc naming is disqualified. Query visibility is half of why zero-trust products keep absorbing DNS.
What a small team should actually run in 2026
The good news: the sub-Enterprise market is well served, and for most small teams the right answer costs little or nothing.
If your team already lives on a VPN overlay, use its DNS. Tailscale’s MagicDNS automatically registers a name for every device on your tailnet, so grafana or nas resolves from any machine, on any network, without touching a record. For a team whose private services all sit on the tailnet, this dissolves the internal DNS problem rather than solving it — there is no zone to manage at all. The equivalent features in other mesh-VPN products work the same way. This is the closest thing to a default answer for teams under about twenty people.
If your private services live in one office or homelab, run a local resolver. Pi-hole is the path of least resistance: it is a full local DNS server (built on FTLDNS/dnsmasq) with a web UI, so you can define local records and get network-wide ad and tracker blocking from the same box that answers your internal lookups. A Raspberry Pi or a container on the NAS is enough. The trade-off is that you own uptime — if the Pi dies and it is your only resolver, the office loses DNS, so set a public upstream as secondary on your DHCP config.
Name things properly regardless of tool. Do not invent a fake TLD like .corp or squat on a real one. RFC 8375 designates home.arpa for exactly this purpose on residential-style networks, and Cloudflare’s own GA examples use corp.internal — .internal being the label the industry has settled on for private zones. Using a reserved namespace means your internal names can never collide with a future public domain, which is a real and recurring failure (ask anyone who used .dev internally before Google launched it as a public TLD).
Graduate deliberately, not aspirationally. The moment one of the three signals above turns true — usually split-horizon — you move from “naming convenience” to “DNS infrastructure,” and that is when managed offerings with views, policies, and audit logs earn their price. Cloudflare’s Enterprise gate will not fit a ten-person team’s budget today, but the feature set it just made GA (views over shared zones, policy-routed resolution, API-first changes) is the checklist to shop against, whichever vendor you evaluate.
The cost math nobody writes down
Before pricing any tool, price the status quo. A stale internal name that burns one engineer for two hours a month is roughly twenty-four engineer-hours a year — for many small teams that alone exceeds the total cost of a Raspberry Pi resolver or a mesh-VPN subscription, and it does not count the occasional multi-person incident when a deploy script resolves the wrong box. On the other side of the ledger, a self-hosted resolver is not free either: someone patches it, someone answers when it goes down at 9 a.m., and someone remembers it exists when the office moves. The mesh-VPN route wins the math for most teams precisely because it deletes both columns — no drift to chase and no box to babysit. Managed platforms only enter the equation when the signals above add compliance or split-horizon requirements that the free tier of duct tape cannot meet at any price.
A ten-minute decision path
Run your team through this in order and stop at the first hit. One: if everything private is reachable over a mesh VPN, turn on its automatic DNS and you are done. Two: if services are office-bound, stand up a local resolver like Pi-hole with records under home.arpa or .internal, and add a secondary upstream. Three: if you need split-horizon answers, audit logs on internal queries, or consistent resolution across offices, VPNs, and clouds — you have genuinely outgrown the duct tape, and it is time to price managed internal DNS platforms, Cloudflare’s included, against the engineering hours you are currently spending on drift.
The honest takeaway from this week’s GA is not “everyone needs enterprise DNS.” It is that names-as-infrastructure has become table stakes at every scale, and the tooling below the enterprise tier is now good enough that a small team’s answer should never again be a hosts file in a Slack thread.
