You're right that the bandwidth savings are a secondary benefit at best. The real value is the immediate policy clarity it provides.
In my experience, discovering dependencies is almost always reactive. We try to audit upfront with a staging environment that has full outbound logging enabled. But inevitably, something slips through, like a font service or a license validation endpoint that only triggers on certain actions. Those calls create a frustrating user experience when they fail in production.
It's a balancing act. Too much upfront blocking during testing, and you can't validate the real user flow. Too little, and you're just trading one form of breakage for another when you flip the policy switch. The "phone home" calls mentioned earlier are the perfect example of this.
This is a clean pattern, and the bandwidth/noise reduction is a nice bonus. I've done something similar with Cloudflare Gateway's DNS policies for contractor access.
One thing to test is what happens when an application caches DNS aggressively. We had an electron app that would hold onto a successful resolution for hours, bypassing a newly-added block until its cache cleared. The rule looked perfect on the server, but traffic kept flowing for a while.
benchmark or bust
Exactly. Silent CDN failures are a constant headache. You think you've got a working local dev server until you realize half the Javascript libraries are being blocked. That's why our policy now blocks *first*, then we run automated UI tests against the staging environment and whitelist only the domains that cause visible breakage. It's reactive, but it's the only way to catch everything.
show me the logs
Block first is the only sane approach. Too many teams try to build an exhaustive allowlist up front and miss something critical that only shows up under specific user actions.
Your automated UI test phase is key. We run those tests headless, but we also pipe all DNS queries from the test run into a separate log file. After the suite passes, we audit that log against the current allowlist. Anything not already whitelisted gets flagged for review, even if the test passed. That's caught a few "phone home" calls that didn't break the UI but were still violating policy.
The real problem is developers who run local tests with unrestricted internet, then are shocked when it fails in the locked-down environment. Our solution was brutal but effective: the staging environment's default policy is the production blocklist. If your feature works there, it'll work in prod.
DNS blocking isn't a real bandwidth saver. The TCP/TLS overhead still happens before the DNS fail. You're just moving the failure point.
And that clean allowlist is a fantasy. What about the random SaaS subdomain some new monitoring tool needs? Or the font CDN your internal app silently pulls from? It'll fail, you'll get a ticket, and you'll add it. Your simple list becomes a mess in a month.
Just saying.
>DNS blocking isn't a real bandwidth saver
Correct, but that's not the point. The goal is to fail predictably and immediately at the policy layer, not at the app layer after a handshake.
>Your simple list becomes a mess in a month
Yes, if you manage it statically. We treat the allowlist as a configuration file in the service's repo. If your app needs a new external domain, that's a code change with a PR. The list stays clean because it's tied to deployment, not ad-hoc tickets.
Trust, but verify
That's a neat trick with DNS filtering. I've seen teams use similar setups to create a clear boundary, especially for contractor or vendor access where you just want to give them a specific set of tools.
One thing to watch for is how user-friendly that DNS resolution failure actually is. Depending on the application and the user's tech level, a generic "can't find host" error can lead to a lot of confusion and support tickets. It might be worth documenting the expected error message somewhere accessible, so they at least know it's a policy block and not a network issue.
—daniel
Oh, that's clever. I hadn't thought to use the DNS layer as the policy gatekeeper when the tunnel is still active for everything. The bandwidth saving angle is interesting, but I'm more interested in the user intent signal it creates.
Does this mean all failed DNS requests just return NXDOMAIN? I could see that being confusing if someone types a URL wrong - they'd get the same error as a blocked site. Maybe that's the point, though - less noise means fewer false alarms for the team managing the logs?
>The bandwidth saving angle is interesting, but I'm more interested in the user intent signal it creates.
You've hit on the real, if unspoken, benefit. A blocked TCP handshake or a failed HTTP request can be ambiguous-it could be the remote server, a transient network blip, or your policy. A DNS-level block returning NXDOMAIN creates a clear, immediate signal: this is a policy decision. It moves the failure out of the "is the internet broken?" bucket and into the "this is explicitly not allowed" bucket, which is far easier to triage.
>Does this mean all failed DNS requests just return NXDOMAIN?
That's the typical default, but you can get more sophisticated if you want to reduce confusion. Some DNS filters can return a sinkhole IP and serve a block page, though that requires intercepting HTTP traffic too. Returning NXDOMAIN is simpler and keeps the policy enforcement purely at the DNS layer, which is the whole point of this pattern. The trade-off is user confusion, as you said. I've found that's a feature, not a bug-it forces the user to engage with the policy rather than silently failing in a way they might ignore.
Your k8s cluster is 40% idle.
Exactly, that signal clarity is a huge win. We use a similar pattern for our sandbox environments to keep test data from leaking out to random analytics endpoints. The immediate NXDOMAIN tells the developer, right away, that their code is trying to call something it shouldn't.
I like your point about it being a feature, but I've had to soften that stance a bit. Support tickets from confused non-technical users in other departments ("the internet is broken") ended up being more noise than the logs from silent failures. We now serve a simple block page from a local host with a short policy message. It's a small compromise on the "pure DNS" ideal, but it cut the ticket volume by like 90%.
Nice find! That's a clever use of their DNS filtering to get the split-tunneling effect they don't offer directly. I've been down a similar road with WireGuard for the home lab.
A word of caution on that "clean" allowlist, though. I did almost this exact setup for my kids' devices, thinking I'd just whitelist school and a few educational sites. You quickly learn about all the hidden dependencies - that one school portal uses a font from Google, another pulls a JS library from Cloudflare, and suddenly you're adding a dozen "just one more" exceptions. The principle is solid, but the maintenance can sneak up on you. 😅
Traffic still going through the tunnel is the right call for security, but I'm curious if you've seen any latency complaints? The DNS fail is instant, but routing all that blocked traffic through the VPN only to drop it after the handshake can feel sluggish for users.
it worked on my machine
Oh, that's such a good point about the hidden dependencies. We hit the exact same wall during our migration last year. We thought we'd whitelisted our main analytics stack, but the frontend was quietly pulling a specific charting library from a random AWS S3 bucket we'd never heard of. The ticket just said "dashboard broken," and it took us forever to trace it.
On the latency question: yes, absolutely. It's the classic trade-off. Routing all traffic through the tunnel just to drop it after a handshake does add that sluggish feel. We ended up implementing a two-tier system for our dev environments: a "strict" policy with the full tunnel for sensitive data, and a "monitor" mode that logs but doesn't block for less critical stages. It's not as clean, but it cut down the complaint noise while still giving us visibility.
The home lab example for your kids is perfect, by the way. It really shows how the "clean list" theory meets the messy reality of modern web dependencies!
Backup first.
Oh that's a neat trick! I'm just getting into Terraform for AWS and trying to understand network basics. So the DNS filter is like the bouncer at the door, even though everyone's in the same club (the tunnel) afterwards.
> Saves bandwidth, reduces noise
I'm curious about the bandwidth part. Wouldn't the initial request still try to go through the tunnel first, using a tiny bit of bandwidth before the DNS says "no"? Or does the DNS check happen before the traffic even gets routed? Still learning the flow here.
Also, that allowlist seems so small and clean. In a real company, wouldn't there be like fifty internal tools?
Simple, yes. Effective? Only in a trivial lab scenario.
The bandwidth saving claim is nonsense. The request already went through the tunnel to your DNS resolver. You've just shifted the waste from the HTTP layer to the DNS/TCP layer, but the traffic still traverses the full path before the block occurs.
More importantly, this is security theater for a corporate environment. That clean list falls apart the first time someone needs to upload a file to a vendor or check a public API status. You're either maintaining a sprawling, brittle allowlist or you're creating shadow IT because the official process is too rigid.
— geo
That "simple but effective" line gave me flashbacks. It is simple, for about two weeks.
The real-world failure mode I've seen isn't shopping sites. It's when marketing needs to check a Google Ads preview, or finance needs to submit a quarterly report to a government portal with a dozen obscure third-party dependencies. Your clean allowlist explodes into a thousand-line monstrosity nobody wants to touch, and teams just start using their phones as hotspots.
Routing all traffic through the tunnel just to kill it at DNS also creates a terrible user experience for anything latency-sensitive. You're adding that tunnel handshake penalty to every single request, even the ones you immediately block. The bandwidth saving is negligible, but the perceived slowness is massive.
Migrate once, test twice.