A DNS block page should say that access was stopped by domain policy, identify the requested domain and relevant policy boundary when safe, distinguish a policy block from a network failure, and offer a review path. It should not expose browsing history, internal rule details, administrator identities, or a false promise that the page itself is dangerous.
Replace the dead end with four answers
A useful block page answers four questions in ordinary language: what happened, what was requested, what the reader can do next, and where an authorized reviewer can find evidence. “Access denied” answers only the first, and even that poorly. “The domain example.test was blocked by your organization’s domain policy” distinguishes a deliberate result from a broken connection without accusing the person or overstating the domain’s risk.
| Element | Useful copy | Avoid |
|---|---|---|
| Outcome | Blocked by domain policy | Security violation |
| Target | Requested domain, when appropriate | Full URL or browsing trail |
| Reason | Plain category or policy label | Internal rule IDs and list names |
| Next step | Retry, return, or request review | Disable protection |
| Support evidence | Short correlation code and time | Private log detail on screen |
Use a calm heading and one primary action. A family page might say “This domain is not available for this device” and direct the reader to a caregiver. A team page might provide a request-review link and a short reference code. Avoid moral language, jokes, threat graphics, or claims about intent. Background applications make DNS requests without a person typing a domain, so a block is not evidence that the reader deliberately visited anything.
Say only what the DNS decision proves
The page can accurately say that a DNS policy matched a domain lookup. It usually cannot say which page, video, search, file, chat, or person caused it. DNS does not reveal URL paths, page contents, search terms, in-app messages, voice audio, or full browser history. It also does not establish that a domain is malicious: a manual rule, category choice, age boundary, or mistaken classification may have produced the same outcome.
Extended DNS Errors define machine-readable explanations including “Blocked,” “Censored,” and “Filtered,” but the RFC warns that extra text may contain sensitive information and must not be assumed trustworthy.3 Treat protocol detail as diagnostic input, not ready-made user copy. Translate the known policy outcome into a neutral sentence, and keep technical codes in the review evidence where an authorized operator can interpret them.
Do not promise that every blocked lookup can display a page. Some policies answer with NXDOMAIN, REFUSED, no data, or another response rather than directing a browser to a web server. Non-browser applications may never render HTML. HTTPS also authenticates the requested hostname, so redirecting it to a different server can cause a certificate warning before any explanation appears. Design an understandable resolver outcome even when no page is visible.
Separate reader copy from review evidence
The reader needs little information. A reviewer may need the time, resource, policy boundary, queried name, matched action, and a correlation value. Do not put that whole record on a shared screen. A television, classroom display, lobby device, or meeting-room browser may be visible to people who have no right to see policy or activity. Show the minimum useful explanation, then let an authenticated and authorized role retrieve the narrow evidence needed for review.
- Display the requested domain only when that does not reveal sensitive context to bystanders.
- Use a short-lived or non-guessable correlation code rather than embedding log data in a URL.
- Never place internal policy names, administrator email addresses, user identity, or retained-history excerpts in public page markup.
- Provide an accessible title, readable contrast, keyboard-reachable actions, and copy that still makes sense without color.
- Localize the user-facing explanation while keeping diagnostic values stable for support.
Build a review path that can actually be used
A review link is useful only when it reaches someone with authority and enough evidence. Ask for the task that failed, affected device or resource, time, domain shown, and urgency. Do not ask the reader to diagnose DNS. The reviewer should confirm that the resource used the expected resolver, identify the matching baseline, enforced, or local rule, verify domain ownership and purpose, and reproduce the complete workflow before changing policy.
If baseline policy caused a false positive, make the narrowest justified resource override and give it an owner and review condition. If enforced Space or Tenant policy matched, a resource cannot bypass it; the authorized policy owner must decide whether the enforced rule itself is wrong. This distinction prevents a friendly-looking “request access” button from implying that every protection is negotiable.
Test the page like a failed workflow
- Trigger a documented harmless test domain from one browser and one non-browser application.
- Confirm the visible message does not identify a person or expose retained activity.
- Follow the review path with a keyboard and a narrow mobile viewport.
- Check that the correlation evidence reaches only an authorized Space or Tenant role.
- Approve a test baseline exception, verify the full task, then remove it.
- Confirm enforced policy still cannot be weakened and record the expected no-page behavior for other response modes.
Test wording with someone who did not design the policy. Ask what they think happened, whether they believe they are being accused, and what they would do next. The correct answers should be “a domain rule stopped this request,” “not necessarily,” and one clear recovery action. If the person instead changes Wi-Fi, disables a browser protection, or repeatedly reloads, the page has not explained the boundary well enough.
Block-page questions
Should a DNS block page name the matched category?
Name it only when the label is accurate, understandable, and appropriate for the audience. A neutral phrase such as “blocked by domain policy” is better when a sensitive category could embarrass someone or reveal more than the reader needs.
Why does a blocked HTTPS site sometimes show a certificate warning instead?
An HTTPS connection authenticates the requested hostname. Redirecting that lookup to a block-page server can create a hostname and certificate mismatch before the browser can show explanatory content. A resolver response code or browser-integrated notice may avoid that problem.
Should the block page include a one-click bypass?
Usually not. A review request is safer than an immediate bypass because it preserves policy authority and creates evidence. If temporary access is appropriate, an authorized role should approve the narrowest resource exception without weakening enforced Space or Tenant policy.
Connect a review to the right Veilty boundary
In Veilty, connect the review to the affected household Space or team Tenant without exposing its retained history on the block page. Invitations are account-scoped and grant no Space or Tenant access by themselves; after acceptance, assigned roles govern controls and retained activity. Baseline policy may be overridden by a justified resource exception, while enforced Space or Tenant policy remains non-overridable. Saved history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted roles, while the resolver still processes live DNS requests. Begin by rewriting one vague “access denied” message around the four reader questions.12