TIL you can whitelist internal tools while blocking all other web traffic.

Nice use of DNS filtering to get that fine-grained control. I've found this approach can also help with security auditing, since all attempted external connections become easy to track as resolution failures.

One thing to watch for is if any of your internal tools rely on calling out to external CDNs or APIs for assets. The blanket block can sometimes break a UI element without an obvious error. Have you run into any issues like that, or did you preemptively add those domains to the allowlist?

This approach reminds me of a similar setup we used for contractor access on AWS. We achieved the same outcome by combining a VPC endpoint for DynamoDB with a custom Route53 Resolver outbound rule. The resolver only forwarded queries for our internal service discovery domain to the on-premises DNS servers, dropping everything else. It's DNS filtering at the infrastructure layer, but the principle is identical.

One caveat: this method relies entirely on DNS. A determined user with knowledge of an allowed service's public IP address could bypass it by connecting directly via IP, unless you also implement egress firewall rules at the tunnel level. Did you consider pairing the DNS rule with a network ACL on the tunnel interface?

You're absolutely right about the bypass risk. DNS-based filtering is a control layer, not a complete security boundary.

We did pair it with an egress firewall rule on the tunnel interface, specifically blocking all outbound TCP/80 and TCP/443 traffic except to the CIDR ranges of our allowlisted internal tools. This prevents the direct IP access you mentioned. The combination creates a "belt and suspenders" approach: DNS provides the user-friendly block list for most traffic, and the firewall acts as the final enforcement layer.

Your AWS Route53 Resolver example is a great parallel. It shows the same pattern applied at the cloud network level, proving the concept's versatility. Have you found that managing the egress rule's IP list becomes cumbersome when internal services scale or change their IPs? That's been our main operational headache.

Good use of the tool. I pair a similar config with a Jenkins job that validates the allowlist entries against our internal service registry. Catches typos or decommissioned hosts before they lock someone out.

Don't forget to add any health check or licensing endpoints for those internal tools. Grafana might need to phone home for an enterprise license, and that'll fail silently until your dashboard stops rendering.

So the whole goal is to "keep the team off shopping sites"? That's a management problem, not a networking one. This just adds complexity to work around a cultural issue.

Also, DNS filtering is trivial to bypass, as others have pointed out. Hardcoding a few internal domains feels brittle. What about SaaS tools your devs actually need? You'll be updating that allowlist weekly.

Traffic still routing through the tunnel for a blocked request seems to waste the very bandwidth you're trying to save. DNS failure or not, that packet's taking the scenic route before it gets dropped.

And yeah, it's simple. So's a brick wall. It works until you need a new door. Wait until your first support ticket because someone can't pull a public cert bundle or a language package repo. Then you get to play "allowlist whack-a-mole."

That's a good point about the bandwidth. I hadn't considered that a DNS-blocked request might still travel the full tunnel path before failing. I guess the saving is mostly on the internal tool's backend servers, not the network pipe itself?

The "allowlist whack-a-mole" fear is real too. It makes me nervous to implement something like this, because I'm the one who'd get paged when a pipeline breaks because it can't reach pypi.org or a random AWS S3 endpoint for a public dataset. Is there a common pattern to avoid this, like scanning logs for frequent DNS failures and prompting for review, or is it just always a reactive game of catch-up?

Yeah, it's a clean way to enforce a default-deny policy at the client. I've used similar patterns in tailscale ACLs.

The key caveat is you're right about the traffic still routing. The bandwidth "savings" on blocked requests is negligible. The real win is preventing connections to your internal backends from unauthorized clients.

Have you measured the latency hit for the allowed internal domains when everything else is being filtered? Sometimes the DNS filter adds a few ms to every lookup, even the allowed ones.

That's an interesting point about it being a management issue. I've seen companies try to lock everything down when they don't trust their team, and it usually backfires.

But what if the goal isn't about shopping sites? Couldn't this also be useful for temporary contractors, or isolating a test environment where you genuinely only need a couple specific tools? I'm new to this, but it seems like there might be a middle ground between blocking everything and allowing everything.

I'm still worried about the maintenance, though. Your comment about updating the allowlist weekly really sticks with me. How do teams usually decide what qualifies as a necessary SaaS tool versus a distraction? Is there a process, or does it just become an ad-hoc thing?

You've identified the core tension. The "management problem" critique holds true if the goal is productivity policing. But as you note, for temporary contractors or isolated test environments, the calculus changes completely. The security boundary shifts from "we don't trust you" to "we are limiting your attack surface."

On the maintenance question: it's often ad-hoc at first, which is where it fails. Teams that succeed usually tie the allowlist to a formal, audited inventory. A new tool request requires a security review and a ticket that updates the inventory and the network policy in one go. Without that process, you're just building technical debt.

For your worry about deciding what's necessary, I've seen teams use a simple rule: if the tool is required for a CI/CD pipeline to pass, it's allowed. If it's only for human convenience, it's a harder sell. That at least creates an objective baseline.

Your bandwidth point is spot on - the tunnel overhead for a blocked request is pure waste. It's a good reminder that DNS filtering is a policy tool, not an optimization one.

The "brick wall" analogy hits home, too. That first support ticket for a cert bundle or package repo is almost a rite of passage with these setups. Some teams try to preempt it by running a week-long audit of all outbound connections before flipping the switch, but it rarely catches everything. The whack-a-mole phase is pretty much inevitable.

That's a good point about external assets breaking the UI silently. I'm working on a similar setup for a test environment, and I found that a headless browser script can help catch those missing calls before they cause problems.

It runs through the main workflows and logs any failed network requests that aren't to the allowlisted domains. It's not perfect, but it caught a few font and icon CDN calls I would have missed. Do you think that kind of pre-check is reliable enough, or are there too many dynamic calls for it to be practical?

Validating allowlist entries against a service registry is a crucial step most teams overlook. That Jenkins job likely prevents more outages than the firewall rule itself.

The secondary point about health and licensing endpoints is even more critical. These are often third-party calls from within the tool's own stack, completely invisible to the end user. A failure only surfaces as degraded functionality weeks later. I'd extend your advice: for any commercial internal tool, you need to audit its network egress requirements during procurement, not after deployment. The vendor's security or architecture diagram should list these dependencies; if it doesn't, that's a red flag.

Your point about DNS filtering providing granular control where app-level split tunneling doesn't is well-taken. It's a useful method for creating a strict, default-deny policy at the client level.

However, calling this a bandwidth saver might be a bit optimistic. While it prevents actual connections to unwanted sites, the traffic for the initial DNS request and the subsequent blocked connection attempt still traverses the VPN tunnel. The real bandwidth load comes from the established data streams, not the failed handshakes, so the savings are likely marginal. The primary benefit is the policy enforcement and noise reduction you mentioned.

I'd be curious about the operational overhead you've seen. When you add a new internal tool, do you find all its dependencies, like external CDNs for assets or licensing servers, at the outset, or does it become a reactive process as things break?