Beyond Public DNS: Securing Australian Agency Client Networks with Cloudflare Internal DNS and Managed Hosting

The Hidden Risk in How Agencies Expose Client Infrastructure

An agency managing twenty client websites typically has staging environments, client portals, internal dashboards, and admin panels all sitting on the public internet, protected by little more than a login form and hope. Every one of those endpoints is a potential entry point. Every subdomain a developer spins up for a “quick test” becomes another line in a DNS zone file that an attacker can enumerate. This isn’t hypothetical. It’s the default state of most agency infrastructure, and it’s exactly why a growing number of Australian agencies are re-architecting how their DNS actually works.

Public DNS itself isn’t broken. The problem is agencies keep using it for things that were never meant to be public in the first place. Staging sites, internal tools, client reporting dashboards, CI/CD webhooks, none of it needs to be resolvable by anyone on earth. But setting up separate internal resolution has historically been a pain, so most agencies just leave everything on public-facing records and hope obscurity does the job. It won’t. That’s not a security model. That’s a liability waiting for a scanner to find it.

What Is Cloudflare Internal DNS and Why Does It Matter for Agencies?

Cloudflare Internal DNS is a private DNS resolution service that lets organisations create DNS records only resolvable by devices and networks enrolled in their Cloudflare Zero Trust environment. Internal hostnames never touch public DNS zones or certificate transparency logs. Instead of publishing staging.client-project.com to the entire internet, an agency creates that record inside a private zone that only resolves for authenticated team members connected through Cloudflare’s WARP client or configured gateway policies.

Here’s why this matters for agencies specifically: the sheer number of transient, sensitive, or client-confidential environments running at any given time. A public relations firm doesn’t want a competitor finding an unannounced campaign microsite by brute-forcing subdomains. A web development agency doesn’t want a disgruntled ex-employee still able to resolve internal build servers six months after they’ve left. Internal DNS closes that visibility gap by design. Not by convention, not by luck.

It also solves a quieter problem: certificate transparency logs. Every certificate issued for a publicly resolvable subdomain gets logged permanently, searchable by anyone with five minutes and a browser. Agencies that have used public DNS for staging environments for years often have no idea their entire subdomain history, abandoned client projects included, is sitting in a public, searchable ledger right now. Internal DNS combined with private certificate issuance stops that record from ever being created.

How Zero Trust Security Changes the Agency Threat Model

Zero trust security assumes no user or device is trustworthy by default, regardless of whether it’s inside or outside the traditional network perimeter, and it demands continuous verification for every single request. For agencies, this replaces the old “if you’re on the office Wi-Fi or VPN, you’re trusted” model with something far more precise: every request to every internal resource gets authenticated and authorised individually.

That shift matters because agency work rarely happens in one office anymore. Contractors, remote designers, offshore developers, account managers working from a client’s boardroom, all of them need access to internal systems. Not all of them need access to everything. A zero trust model built around Cloudflare’s Access and Gateway products lets an agency define exactly who can resolve and reach a given internal hostname, and revoke that access instantly the moment a contractor’s engagement ends. No firewall rules to touch, no VPN configs to unpick.

Combine zero trust with private network DNS resolution and an attacker who compromises a single laptop doesn’t get a map of your entire client portfolio. They get nothing. The DNS records that would tell them what exists simply don’t resolve outside the authenticated network.

A Practical Scenario

Picture an agency running client staging sites on subdomains like staging1.agency.com, staging2.agency.com, and so on, all sitting on public DNS behind nothing more than a basic auth prompt. One misconfigured staging site gets indexed by a crawler and exposes a client’s unreleased product pricing months before launch. The agency’s reputation and the client relationship both take a hit that has nothing to do with a “hack” in the traditional sense. It’s poor DNS hygiene, full stop. Under an internal DNS model, that staging environment would never have been resolvable outside the agency’s authenticated network. The crawler would have found nothing at all.

How to Implement Private Network DNS for Client Environments

Moving internal-only assets off public zones and into an authenticated resolution layer is a structured process, not a flip of a switch. Here’s how agencies typically approach the migration:

• Step 1: Audit existing DNS records. Pull the full zone file for every domain the agency controls. Flag anything that doesn’t need to be publicly resolvable: staging subdomains, internal dashboards, database admin panels, CI/CD endpoints.
• Step 2: Separate public and private zones. Genuinely public-facing production sites stay on standard public DNS. Everything else moves into a Cloudflare Zero Trust private DNS zone.
• Step 3: Enrol devices and staff. Deploy the Cloudflare WARP client across agency laptops and any contractor devices that need internal access, tying resolution rights to identity rather than network location.
• Step 4: Define Gateway policies. Set explicit rules for which authenticated identities can resolve which internal hostnames. An all-or-nothing internal network defeats the purpose.
• Step 5: Reissue certificates privately. Use private CA issuance for internal-only hostnames so they never show up in public certificate transparency logs.
• Step 6: Decommission old public records. Once internal resolution is confirmed working, remove the old public records entirely. Leaving them dormant defeats the point too.

This isn’t a weekend project, particularly for agencies carrying a large legacy footprint of client subdomains built up over years. It’s the kind of infrastructure change that works best handled alongside a broader hosting and security review, which is exactly where managed hosting for agencies becomes relevant. The DNS layer and the hosting environment need to be designed together, not bolted on separately after the fact.

Where Managed Hosting Security Fits Around Internal DNS

Managed hosting security is the server-level, network-level, and application-level protection a hosting provider maintains on an agency’s behalf, and it’s the layer internal DNS alone can’t replace. Private DNS resolution stops unauthorised users from finding a resource. It does nothing to stop a vulnerability being exploited once someone, legitimate or compromised, actually reaches the server.

That’s why internal DNS and managed hosting security are complementary, not interchangeable. A well-configured Cloudflare Zero Trust setup keeps staging environments and internal tools invisible to the public internet. A properly managed hosting environment makes sure that once someone does connect, staff, contractor, or client, the underlying server is hardened, patched, monitored, and isolated from other client workloads.

For agencies running multiple client sites, this means asking hard questions about hosting architecture. Are client sites actually isolated from each other, or sharing resources in a way that lets one compromised site take down the others? Is there real-time malware scanning and file integrity monitoring on the server itself, not just at the DNS edge? Are backups isolated from the live environment, so a breach can’t wipe out your recovery options too? Get these answered before you build an internal DNS layer on top of infrastructure that isn’t itself secure, not after. Agencies serious about this should get in touch for a free migration assessment before committing to a new architecture, so the hosting foundation and the DNS strategy line up from day one.

For agencies running WooCommerce stores or high-transaction client sites, this pairing matters even more. Business Class Hosting environments handling live customer payment data benefit enormously from having admin and staging environments moved off public DNS entirely. That reduces the attack surface around the parts of the stack that actually process sensitive data, which is where it counts.

Building an Agency Web Solutions Strategy Around DNS Privacy

Agency web solutions that treat DNS privacy as a core design principle rather than an afterthought are harder to compromise and, just as importantly, far easier to defend in a client security questionnaire. Enterprise and government clients increasingly require agencies to demonstrate exactly this kind of architecture before signing off on a project, particularly under frameworks influenced by the Australian Cyber Security Centre’s Essential Eight, which explicitly pushes for restricting administrative privileges and hardening internet-facing services.

Agencies that can point to a documented internal DNS and zero trust access model hold a genuine competitive advantage in pitches and procurement, especially for government, finance, or health sector clients where security posture gets scrutinised line by line. This stopped being a defensive measure a while back. It’s a sales asset now.

Practically, that means standardising client onboarding to include a DNS classification step: every new hostname gets tagged public or internal at the point of creation, not retrofitted six months later when someone notices. It also means hosting infrastructure decisions, whether that’s Managed VPS Hosting for isolated client workloads or First Class Hosting for high-traffic production sites, get made with DNS architecture in mind from the outset. Treating hosting and DNS as separate procurement decisions, handled by different people at different times, is how agencies end up with the mess described at the top of this article.

What to Do Next

Start by auditing every DNS record your agency currently controls. Categorise each one honestly: genuinely public, or something that should never have been internet-facing in the first place. Most agencies find the second category is a lot bigger than they expected. From there, work out whether your current hosting provider can actually support a Cloudflare Zero Trust integration properly, with server-level isolation and hardening to match the DNS-level privacy you’re building.

Not sure your existing hosting setup is ready for this? Compare our hosting plans to see which environment fits your client portfolio, or read more about Black Label Hosting to see how we treat security as a foundational part of managed hosting rather than a bolt-on. For agencies running smaller client sites that still need this level of care, Essentials Hosting gives you a properly hardened starting point without the overhead of enterprise infrastructure you don’t need yet. And for businesses outside the agency world weighing up the same questions, the same principles apply under managed hosting for business.

Does Cloudflare Internal DNS cost extra on top of a standard Cloudflare plan?

Internal DNS and Zero Trust features sit within Cloudflare’s Zero Trust product suite, separate from standard DNS and CDN services, and are typically billed per user seat. Check current Cloudflare Zero Trust pricing directly, tiers and inclusions shift periodically.

Can internal DNS records still be discovered through certificate transparency logs?

Not if certificates for internal hostnames are issued through a private certificate authority rather than a publicly trusted one. Public CAs are required to log every certificate they issue, so any hostname using a public cert is discoverable regardless of how private your DNS is.

Does moving staging environments to internal DNS break existing client workflows?

It requires client-facing or contractor devices to be enrolled in the Zero Trust network via WARP or configured access policies. That’s a one-time setup step. Once enrolled, resolution works transparently and staging URLs function exactly as they did before, just now only for authorised users.

Is internal DNS a replacement for a VPN?

No. Internal DNS controls what hostnames can be resolved. Zero Trust Access and Gateway policies control what authenticated identities can actually reach and do once connected. Together they replace the broad network access a traditional VPN grants, but they’re distinct layers doing different jobs.