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.
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
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.