Handle a guest exception as a temporary, documented change: confirm the business task, reproduce the failure on the guest network, and identify the exact hostname and policy outcome. Allow only what the task needs, preserve enforced protection, assign an owner and review point, retest, and remove stale access.
Triage the task, not the category
A visitor may need a supplier portal, document-signing service, payment page, travel system, or client-hosted demonstration that the guest policy blocks. Start by recording the task and urgency, not by assuming the filter is wrong. Ask for the visible hostname, exact time, affected guest network, device type, error, and a contact who can confirm success. Avoid collecting page contents, credentials, or more personal detail than support requires.
Reproduce the problem from the same guest path. Check Wi-Fi association, captive-portal completion, address assignment, routing, authentication, certificate errors, and the remote service before changing DNS. Then confirm which resolver the device actually used and whether a DNS policy outcome exists. Cloudflare documents DNS policy as distinct from network and HTTP policy, a useful reminder that a browser error alone does not identify the failing layer.2
DNS can allow or block a hostname lookup, but it cannot read the page path, contents, search terms, form data, messages, files, voice audio, or full browser history. It cannot permit one page while denying another when both use the same hostname. Modern business services also rely on authentication, content-delivery, API, and telemetry hostnames, so the visible domain may not be the blocked dependency.
Choose the smallest reversible change
| Question | Record | Avoid |
|---|---|---|
| What must work? | One named business task | General unrestricted access |
| Where? | Affected guest resource | Employee and public networks together |
| What changes? | Exact required hostname | Whole category or unrelated domain family |
| How long? | Owner and review point | Unowned permanent bypass |
| How proved? | Task plus security retest | Closing the ticket after one page loads |
A classification matters. If a business site is blocked by a broad content category and the business purpose is legitimate, a resource-scoped hostname allowance may be proportionate. If it is blocked as malware, phishing, command-and-control, or another enforced threat, do not bypass that protection for convenience. Ask the security owner or provider to validate the classification, offer a separate safe way to complete the task, and report a suspected false positive through the threat-source process.
Keep this workflow distinct from meeting-room and demo exceptions. Managed room equipment should have its own resource and known conferencing dependencies. A supervised demonstration may use a separately isolated resource for a known client dependency. Neither case justifies changing the normal public guest baseline. A guest notice should explain the support route and filtering boundary, but it is not approval for unlimited exceptions.
Run the guest exception checklist
- Record the business task, requester, guest resource, urgency, owner, and review point.
- Reproduce the failure and rule out Wi-Fi, portal, routing, authentication, and remote-service faults.
- Confirm the active resolver, exact DNS policy outcome, classification, and hostname dependency.
- Check that the requested allowance cannot override enforced Tenant protection.
- Allow the smallest justified hostname only on the affected guest resource.
- Retest the complete task, a normal allowed site, and a provider-owned harmless block-test domain.
- Record the result, notify the requester, and remove or reapprove the exception at review.
Do not test with a live malicious domain. Use a provider-owned harmless test hostname for the block outcome and a known ordinary hostname for the allowed path. Clear relevant client or resolver caches when the platform permits, then test from the visitor device. AdGuard DNS documentation shows how query-log outcomes can lead to a narrow unblock action; regardless of provider, require a reason and later review rather than treating a log button as sufficient approval.3
Close the loop after access works
Successful access is not the end of the change. Record which hostname was required, which policy caused the block, what was tested, who approved the exception, and when it will be reviewed. Check aggregate results first. Open detailed retained activity only for the named support question and shortest useful period. A lookup may come from background software, so it neither identifies a visitor reliably nor proves intent.
At review, remove the allowance and retest if the visit or task has ended. If the dependency remains common and legitimate, decide deliberately whether it belongs in the guest baseline; do not let repeated temporary changes become policy by accident. If the same threat source repeatedly blocks essential business services incorrectly, review the source and submit evidence rather than accumulating a web of permanent allowances.
Use the support record to improve future triage without building a dossier about visitors. A compact operational record can retain the hostname, classification, affected resource, decision, approver, tests, and closure while omitting unrelated activity. Reviewers should be able to tell whether the exception fixed the stated task and whether it still exists. They should not have to reconstruct a person's browsing. This keeps the evidence proportional and makes recurring false positives visible to the policy owner.
Common mistakes include allowing the visible parent domain before finding the failing dependency, widening a whole category, changing every network, overriding a threat block, retaining excessive activity, and forgetting rollback. Another is promising a fixed duration that the control cannot enforce automatically. Use a real operational review point, assign an owner, and remove the rule manually when required. The process is trustworthy only when the team can explain both the exception and its end.
Guest exception questions
Should a guest exception allow an entire business category?
Usually not. Identify the hostname needed for the stated task and allow the smallest dependency that works. A category-wide bypass affects unrelated visitors and is harder to review.
What if the domain is blocked as malware or phishing?
Do not override an enforced threat protection just to end a support call. Validate the domain and classification through the provider or security owner, use another safe business path, and escalate a suspected false positive.
Can a DNS exception allow one page but block another on the same domain?
No. DNS policy works with hostnames, not URL paths or page contents. If allowed and blocked pages share a hostname, DNS is too coarse for page-level access.
Narrow the exception in Veilty
In Veilty, keep the public guest network as a distinct resource in the appropriate Tenant. A resource may override its Tenant baseline for a justified hostname allowance, while enforced Tenant policy takes precedence and cannot be weakened. Review aggregate outcomes before opening retained activity. Saved activity belongs to the Tenant, is end-to-end encrypted with user-held keys, and can be opened only by members whose Tenant roles allow access; an account invitation or account membership alone grants no Tenant access. The resolver still processes live requests. Verify the business task and a harmless block test, record the owner and review point, then remove stale access.1