Meridian Electric Cooperative needs one specific page on a shared corporate SaaS domain permitted while blocking every other page on that same domain for back-office users. Why is a DNS filter profile the wrong tool for this specific requirement, even though it could block the whole domain easily?

DNS filtering operates entirely at the name-resolution stage: it evaluates the domain being queried and decides whether that name resolves, with no visibility into anything that happens after the connection to the resolved address is made, including which specific page or path a user requests on that site. That makes it well suited to an all-or-nothing decision about a domain but structurally incapable of allowing one page while blocking the rest of the same domain, since the DNS query for the domain looks identical regardless of which page the user intends to visit next. The option suggesting DNS filtering can't reliably block domains at all misdescribes a mechanism that works fine for whole-domain decisions — its limitation here is granularity, not reliability. Requiring SSL deep inspection to evaluate a domain is also incorrect; DNS filtering acts on the DNS query and answer, which are unencrypted regardless of what protocol the later session uses. And DNS filtering does not support a path-based entry at all, since a DNS query never carries a URL path to match against. For Meridian's actual requirement, a static URL filter entry with a path-specific Allow, paired with a broader category or domain block, is the mechanism with the visibility to make that distinction. Confirm the right tool is in play by checking whether the log entry for the blocked/allowed request shows a DNS filter or a web filter action.