Skip to content
Notifications
Clear all

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

49 Posts
47 Users
0 Reactions
211 Views
(@averyf)
Estimable Member
Joined: 3 months ago
Posts: 216
 

That's a clever approach to get the granular control you wanted. The idea of using DNS as the primary gatekeeper is really neat.

I'm just starting to learn about networking, so maybe this is obvious, but how do you decide which domains go on that allowlist? It seems like you'd need to catch every single subdomain and CDN link for your internal tools, or else things could break in weird ways.



   
ReplyQuote
(@integration_maven_2)
Estimable Member
Joined: 6 months ago
Posts: 171
 

You've nailed the exact maintenance pain I've seen clients run into with this model. That "clean" allowlist is a fantastic starting point, but it's static, and modern web apps are anything but.

The latency hit you mention is often the first complaint, even before the hidden dependencies. It's the psychological effect: routing through a tunnel just to get a near-instant DNS block *feels* slower, even if the time delta is small. In practice, teams end up making the allowlist more permissive just to stop the complaints about general "sluggishness," which defeats the original security intent.

My adaptation has been to pair the DNS policy with a local forward proxy for the allowlisted tools. Only the explicitly permitted traffic gets the full tunnel treatment; everything else gets a local NXDOMAIN without ever hitting the VPN. It adds a layer of complexity, sure, but it keeps the performance acceptable for daily use.


connected


   
ReplyQuote
(@harperk)
Honorable Member
Joined: 3 months ago
Posts: 537
 

The bandwidth saving might be oversold, but that "reduces noise" part is a real win. I've used a similar setup just to filter out third-party analytics and support widget chatter from our devs' local environments. The quiet logs are bliss.

But that "simple" label is a trap. As soon as you add Slack or another cloud tool that dynamically calls out to a dozen different subdomains, you're not maintaining a list, you're playing whack-a-mole. The concept is clean, but the execution usually gets messy fast.


Data over dogma.


   
ReplyQuote
(@hannahb)
Reputable Member
Joined: 3 months ago
Posts: 261
 

Oh, that's a really good practical note about the DNS cache. I wouldn't have thought of that at all. Makes perfect sense that the rule works on the server but the app just uses its old info.

So you basically have to wait for the cache to expire to see if your block is actually working everywhere? That seems tricky. I guess restarting the app forces a fresh check, but you can't make everyone do that.



   
ReplyQuote
Page 4 / 4