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

Nice find! That's a clever way to work around the limitations of app-based split tunneling. I've seen similar DNS filtering used as a training step for new tool adoption, actually. It forces the team to learn the direct URLs for the critical systems instead of relying on search or bookmarks, which can be surprisingly helpful for onboarding. The bandwidth saving might be small, but the focus gain is real.

> the packet's taking the scenic route

Exactly. The savings are from blocking the data stream, not the setup. The initial routing is a fixed cost.

You're right about the whack-a-mole. We log all DNS failures for a month before switching to default-deny. It catches about 80% of the deps. The other 20% are the painful ones.

80% is a solid capture rate, but that remaining 20% is where the real engineering time gets burned. We found those were almost always calls from a library or SDK, not the main app logic.

The headless browser audit mentioned earlier helps with some of it, but you still miss things like telemetry pings from a monitoring agent or licensing checks from a CLI tool.

I've found the bandwidth saving from these setups to be negligible unless you're dealing with very high request volumes to blocked sites. The real performance hit is routing all traffic through the VPN tunnel, which adds latency. Have you measured any impact on page load times for your allowed internal tools? That tunnel overhead can sometimes make a snappy internal Grafana feel sluggish.

Your point about noise reduction is valid, but I'd add that DNS filtering alone doesn't block direct IP connections. A determined user could still bypass it by using an IP address or a local hosts file entry for a major site. For a true security boundary, you'd need this paired with a firewall rule on the tunnel endpoint.

Good question about latency. In our rollout, we saw about a 2-5ms increase for resolved DNS queries to allowed domains, which was noticeable for some API calls but not really for web apps. The bigger issue was the increased timeout for *failed* lookups, which added a few hundred ms of perceived slowness before the block page loaded. That's the real user experience hit.

That timeout cost is real. We measured it and found the exact same pattern. The delay on a blocked lookup directly impacted our aggregate P95 response time metric for the VPN gateway, which then triggered capacity alerts.

Reducing the DNS timeout on the resolver from the default 5 seconds to 1 second stopped the slowness complaints. It made the block feel instant. The trade-off is you might miss some legitimate responses from slow upstream servers, but for an internal allowlist, that's an acceptable risk.

You're dead on about the bandwidth savings being theoretical. I ran the numbers in our first pilot and the extra traffic from those blocked handshakes was a rounding error. The real cost, like you said, is the operational toil that comes later.

That "allowlist whack-a-mole" phase is brutal. We thought we'd nailed it after a month of logging, but our first major headache was a design tool that dynamically pulled icon fonts from a random Google CDN subdomain. No one spotted it until a new hire's UI looked broken. Took half a day to track down.

Absolutely! Those hidden SDK calls are the worst. We spent ages trying to figure out why a new internal reporting dashboard was failing intermittently. Turns out the charting library we'd imported had a silent, hard-coded "phone home" to a stats server for version checks. It wasn't in any documentation, and it only triggered on a specific error condition.

Your point about CLI tools is spot-on. We had the same with a data migration utility that would hang for 30 seconds trying to check for updates. The fix was setting an environment variable to disable it, but finding that flag felt like archaeology.

It's not archaeology, it's a failure to audit your supply chain. That library's "phone home" is a data exfiltration risk, full stop. If you're importing it for an internal dashboard, you've now potentially exposed internal tool metadata to a third-party stats server without consent.

The environment variable fix is a band-aid. The real issue is that someone approved a dependency with hidden network calls. This is why software composition analysis and egress testing need to be part of your procurement, not an afterthought when something breaks.

That's such a frustrating scenario. I've seen something similar with an onboarding survey tool that embedded a feedback widget. The widget silently loaded a CSS framework from an external CDN, and it only broke when our network policy changed, leaving the survey pages looking completely unstyled for new hires.

It really does make you question every external dependency. How do you even start auditing for those silent calls? Is it just a matter of monitoring outbound traffic from a test environment before anything goes to production?

That's a clever workaround for NordLayer's split tunneling limits. I've used similar DNS filtering with Perimeter 81, but found the initial setup to be a bit fiddly.

Have you run into any issues with subdomains? We had to allow `*.service.corp.com` because some of our internal tools generate dynamic subdomains for user sessions. The block list kept catching those.

The subdomain problem is a real headache with these filtering setups. We had the same issue with a vendor portal that creates unique subdomains for each client session, like `client1234.portal.vendor.com`. Our static allowlist missed them completely.

Your wildcard solution works, but it opens up a wider attack surface if the base domain isn't fully controlled internally. We've started pairing the wildcard DNS rule with a more specific application layer firewall rule on the tunnel gateway as a secondary check.

Interesting approach. Does this DNS blocking still let the full web traffic try to route through the tunnel before it fails? Or does the DNS failure stop the request entirely? I'm trying to picture the sequence.

Saving bandwidth sounds great, but I'm curious how it handles things like background app pings that aren't strictly web traffic.

That's a smart use of DNS to create a quasi-proxy. I like it because it keeps the tunnel's routing intact for security posture.

But you're still chewing up a TCP handshake and TLS negotiation before the app realizes there's no host to talk to. For a few users it's fine, but at scale those failed connections add up on your gateway. Have you seen any spike in RST packets or connection errors in the tunnel logs?

Also, what's your fallback for when someone legitimately needs to hit docs.github.com or stackoverflow.com to fix a production issue? Do you have a quick-toggle, or does it become an admin request?

The TCP/TLS overhead is real, but our gateway can handle the load. The bigger issue is the noise in the logs makes it harder to spot actual threats.

For your fallback question, we have a break-glass proxy. Engineers can request a 30-minute token to bypass the DNS block for a specific domain, and it logs everything they do. It's a pain, but it makes people think twice about whether they really need Stack Overflow.