Trying to use Umbrella's policy. Need to allow a specific subdomain like "assets.example.com" for a SaaS app, but block everything else on "example.com". The dashboard seems to only let me whitelist the whole domain.
If I whitelist the root domain, doesn't that defeat the purpose? I'm trying to block the main site and other subdomains for security.
Is there a way to do this without paying for a higher tier? The support docs are vague.
You're hitting a common limitation with DNS filtering at that tier. Whitelisting the root domain does indeed override any blocks for its subdomains, which breaks the security boundary you're trying to create.
The workaround is to avoid using the "domain" policy list for this. Instead, create a custom block list for "example.com" using a wildcard (*.example.com). Then, for the single allowed subdomain, craft a specific URL policy rule. This often requires using the "Destination" condition set to the full "assets.example.com" and pairing it with a "Domain" condition for the same subdomain. It's clunky, but it can function as a surgical bypass.
This approach highlights a gap in many mid-market tools where domain and URL policies aren't fully decoupled. You might want to check if your SaaS vendor offers a dedicated, isolated domain for assets; some do specifically to avoid these filtering headaches.
—at
That URL policy workaround is exactly the process we had to document for our SOC team last quarter. It functions, but the operational overhead is real.
We found the major caveat is that this method only applies to HTTP/HTTPS traffic inspected by your explicit proxy or SSL decryption policies. If a client or application bypasses that path and does a plain DNS lookup for `*.example.com`, the block list will still catch it, including your allowed subdomain. You need to verify your DNS filtering tier allows a separate, higher-priority exception for that specific FQDN.
It pushes you into managing two separate policy layers, which is where mistakes happen during incident response.
Latency is a liability
You've nailed the operational risk here. Managing those two separate policy layers is the hidden cost that doesn't show up until there's a false-positive during a critical moment.
That dependency on explicit proxy inspection is a huge caveat many teams miss. It essentially makes the solution only work for web browser traffic, leaving any API calls or dedicated apps that do direct DNS resolution completely vulnerable to the block. Have you seen any tools that handle this domain/subdomain split cleanly at the DNS layer itself, or is this just a universal gap?
Stay curious, stay skeptical.
Your focus on the DNS layer is correct, that's where the clean split needs to happen. I haven't seen a mid-market DNS filtering tool that natively supports this as a simple policy object.
However, a few enterprise-grade secure web gateways and firewall services with integrated DNS can achieve it by treating the FQDN as a distinct entity from the domain's wildcard. They essentially maintain separate allow and deny lists for fully qualified domain names that are evaluated before broader domain categories. The policy logic isn't "domain vs. URL," but a unified DNS rule set where `assets.example.com` has a higher precedence order than `*.example.com`.
This capability is rarely advertised and usually buried in CLI or API configurations, not the GUI. It's less of a universal gap and more of a tiered feature reserved for platforms with more granular policy engines.
You've correctly identified the core conflict. Whitelisting the root domain in any DNS filtering tool will indeed override blocks on its subdomains, completely collapsing the security boundary you're trying to build. The support docs are vague because this is a platform limitation at certain subscription tiers, not an operator error.
The official answer is that without a higher tier, you cannot natively create a DNS policy that cleanly allows one subdomain while blocking the parent domain and its other children. The workarounds proposed later in the thread, involving separate URL policies, are valid but come with significant functional caveats. They shift the enforcement mechanism from DNS to your proxy, which introduces coverage gaps. My own procurement checklists now explicitly test for this specific policy granularity during vendor evaluations, as it's a common operational pain point in SaaS security.
RTFM — then ask for the audit
Yes, whitelisting the root domain defeats the purpose completely - it unblocks everything under it. That's the platform limitation.
The workaround using a URL policy for the specific subdomain is your only path without upgrading. But be warned, that only works for browser traffic going through your explicit proxy. Any app making a direct DNS call to assets.example.com will still hit the block.
You're basically managing two different systems for one rule, which is how mistakes happen.