A blocked site may still load because the device reused a cached answer or open connection, sent DNS through another resolver, matched a different policy scope, or fetched content from additional hostnames. Reproduce the request on the affected device, confirm its resolver and matched action, then change only the rule or path proven responsible.
Do not begin by adding more categories or blocking every hostname visible on the page. First determine whether a new DNS lookup happened. That single distinction separates stale browser state from a policy, routing, or domain-coverage problem and keeps the investigation from becoming a broad allow-and-block experiment.
Separate a page load from a new DNS lookup
DNS normally maps a domain name to data that helps a client reach a service. Recursive resolvers and clients cache answers for the time indicated by DNS data, reducing repeated queries.1 If the browser already has a usable address, an existing encrypted connection, or locally stored content, refreshing the tab may not exercise the new DNS rule at all.
Close the affected page and reproduce from a private window or a clean browser session, but treat that only as evidence, not a universal cache-clearing recipe. Note whether a fresh lookup appears at the resolver during the test. If no query arrives, investigate client cache, browser state, an open connection, a service worker, or another local path before editing server-side policy.
A cached page is also outside DNS filtering's reach. DNS can act on domain lookups and return an allow, block, redirect, or other policy outcome. It cannot erase downloaded page contents, inspect full URLs, read search terms, see in-app chats or voice audio, or reconstruct full browser history. Use browser, endpoint, or application controls when the required action is below the domain layer.
Capture four facts before changing policy
- Name the exact affected device or resource, including the browser or app used for the test.
- Record the typed hostname, not merely the brand or page title, and note any redirect destination.
- Use a short time window with timezone so the request can be distinguished from background traffic.
- Write the expected action and policy scope: block, redirect, allow, or observation only.
These facts prevent two common mistakes: reviewing the wrong device and interpreting a related background hostname as the user's navigation. RFC 9076 notes that DNS traffic may arise from prefetching, advertisements, embedded resources, malware, and applications as well as deliberate visits.2 A row near the event is evidence of a lookup, not proof of intent.
Trace the resolver path that actually won
Test from the affected device on the failing network. Compare the resolver it is expected to use with the resolver that receives the request. Browser Secure DNS, an operating-system encrypted DNS profile, a VPN, mobile data, a private relay, or manually configured DNS can send a query around a router-level policy. Chrome documents that managed administrators can control its Secure DNS mode and templates, illustrating why browser state belongs in the path check.3
- Repeat once on the original network and once on a known comparison path.
- Check browser, operating-system, VPN, and router resolver settings without changing them all at once.
- Confirm IPv4 and IPv6 follow the intended policy path.
- Look for the test request at the expected resolver; absence is a routing clue, not a reason to weaken policy.
Prove which hostname and action matched
Modern sites rarely depend on one hostname. The typed name may redirect to another domain, while authentication, content delivery, or an app backend uses additional names. Start with the name in the address bar, follow documented redirects, and identify the smallest hostname whose successful resolution enables the unwanted journey. Do not block a shared delivery or identity domain solely because it appeared during the test.
Next inspect the action that actually matched. A rule may be attached to another profile, inherited as baseline policy, superseded by enforced policy, limited to log-only observation, or written for a parent domain that does not cover the name being queried. Record the rule identifier, source, precedence, answer, and resource. The configured rule is less useful than the resolver's observed decision.
Make one correction and retest the journey
Correct the narrowest proven cause. Move the device onto the intended resolver path, attach the existing rule to the right resource, change an accidental log-only action, or add the verified hostname. Avoid disabling a baseline, expanding a wildcard, or creating a blanket allow rule. Those changes hide the original fault and create unrelated breakage.
Retest from a clean session on the same device and network. Verify both sides: the target fails in the intended way, and a representative allowed sign-in or work journey still succeeds. Then repeat after the relevant cache lifetime or with a genuinely new lookup. Record the cause, changed scope, evidence, owner, and review date so support does not rediscover the same path later.
Still-loading questions
Does a successful page load prove DNS filtering failed?
No. The browser may reuse an address, connection, service-worker response, or locally cached page without making the lookup you expected. Confirm a fresh DNS request from the affected device and compare its result with the policy event before judging the rule.
Should I block every domain the page contacts?
No. A page can contact shared content, identity, analytics, and delivery domains used by unrelated services. Identify the hostname that enables the unwanted destination, test the whole allowed journey, and avoid broad collateral blocks merely because a domain appeared nearby.
Can an allow rule override every DNS block?
Not necessarily. Rule precedence and scope determine the outcome. In Veilty, a resource can override reusable baseline policy when permitted, but it cannot weaken enforced Space or Tenant policy. Review the matched action rather than assuming the newest or narrowest-looking rule wins.
Verify one scoped Veilty rule
In Veilty, reusable baseline and enforced policies belong to a Space or Tenant. A resource may override baseline policy when permitted, but it cannot weaken enforced policy. Account invitations add membership only; after acceptance, a Space or Tenant role grants scoped access. Retained activity history is scoped, end-to-end encrypted with user-held keys, and visible only to permitted roles, while the resolver necessarily processes live requests. Review one affected resource and short failure window, make the narrowest proven correction, and verify one allowed and one blocked journey.