Yes. Give the guest network a security-only DNS policy that blocks well-supported malware, phishing, and command-and-control domains. Keep content preferences and person-level tracking out of scope, explain the control, verify it with a harmless test domain, and review false positives. DNS filtering governs lookups; it does not inspect pages, files, or messages.
Choose threats, not tastes
A guest network has a simple job: give visitors limited internet access without extending the trust of the employee network. Protective DNS can reduce exposure to domains associated with phishing, malware delivery, botnets, and command-and-control activity. NIST defines name-resolution filtering as DNS infrastructure applying security policy during resolution, including refusing to resolve domains linked to phishing or malware command and control. That is a defensible visitor-network purpose; judging lawful interests or measuring productivity is not.2
Write the boundary before choosing lists: “The guest resolver blocks domains identified as security threats; it does not enforce employee browsing rules.” Exclude adult-content, social-media, streaming, shopping, and political categories from this policy. If a location has a separate legal or operational restriction, review and communicate it on its own merits instead of disguising it as malware protection. This article stays with security-only filtering, not acceptable-use wording, meeting-room equipment, contractor access, or general guest privacy.
DNS filtering can allow, block, or redirect a domain lookup according to policy. It cannot read a URL path, webpage, download contents, search query, in-app chat, voice call, or full browser history. An allowed lookup does not prove a connection completed, and a blocked lookup does not prove human intent. Keep endpoint security, network isolation, patching, identity controls, and abuse handling as separate layers.
Separate the guest resolution path
Create a guest SSID or equivalent network segment rather than attaching visitors to the trusted office network. Give that segment its own resolver assignment and policy boundary. CISA guidance for guest networks emphasizes separating guest traffic and telemetry from organizational traffic. DNS policy does not create that network isolation, so confirm client isolation, internal-route restrictions, and firewall boundaries with whoever owns the network.4
| Decision | Minimum record | Avoid |
|---|---|---|
| Purpose | Block known security threats | Productivity or morality claims |
| Scope | Guest segment only | Employee, contractor, and guest traffic mixed |
| Identity | Network or resource label | Assuming a lookup identifies a person |
| Visibility | Minimum needed for support and security | Open-ended browsing review |
| Exception | Exact hostname, reason, owner, review date | Permanent category-wide bypass |
Check which resolver guests actually use. A VPN, browser secure DNS, operating-system privacy feature, or manual setting can displace the resolver advertised by the network. Record that limitation instead of claiming universal enforcement. Do not break encrypted DNS indiscriminately or weaken a visitor device merely to improve coverage statistics. Decide whether an unsupported path receives limited access, a clear support explanation, or no access.
Apply and test the minimum policy
- Name an owner and write the security-only purpose in one sentence.
- Confirm the guest segment cannot reach trusted internal networks and document its actual DNS path.
- Assign a distinct guest resource to a narrow malware, phishing, and command-and-control baseline.
- Decide whether operational activity is retained at all, who may review it, and when it is removed.
- Test the expected resolver and a provider-owned harmless block-test domain from two representative guest devices.
- Test sign-in portals, conferencing, software updates, accessibility tools, and ordinary web access.
- Document rollback, the support contact, exception approval, and a recurring policy review.
Never validate with a live malicious domain. A safe test must prove both sides: a harmless test hostname receives the expected block response, while ordinary work and visitor tasks still resolve. Repeat after router, DHCP, firewall, captive-portal, or provider changes. If the expected resolver is not active, the test fails even if the internet appears usable.
Review without turning logs into surveillance
Review aggregate health first: resolver reachability, volume of security-policy outcomes, false-positive reports, and unresolved support failures. Open detailed retained activity only for a named security or support question and only for the shortest useful period. Shared addresses, caching, and background applications make person-level conclusions unreliable. Preserve the decision and remediation record, not a speculative story about a visitor.
Set a review calendar that tests whether the policy is still as narrow as its purpose. Ask whether every enabled threat source remains useful, whether blocked essential services produced support requests, whether old exceptions still have owners, and whether the public notice matches the live settings. Sample each supported device class after network changes. If the team cannot explain why a category is enabled or why activity is retained, pause that choice and return to the minimum security baseline. The review should also confirm that guest access expires or changes predictably, network administrators can restore the previous resolver configuration, and the escalation route reaches someone who can distinguish a DNS failure from a captive portal, firewall, or application problem. These checks make the control maintainable without turning ordinary visitor traffic into an investigation queue.
Common mistakes are copying the employee policy onto guests, mixing content categories with threat protection, identifying people from device names, retaining activity without a purpose, and widening an allow rule because one service failed. Repair a false positive with the exact hostname when possible, verify both the service and the threat test, then set a review date. If a threat source repeatedly misclassifies essential services, review the source rather than accumulating exceptions.
Security-only guest filtering questions
Can DNS filtering see which pages a guest reads?
No. DNS handles domain lookups. It cannot see page paths, page contents, search terms, in-app messages, voice audio, or a complete browser history.
Should a guest policy block every risky-looking category?
Not for a security-only goal. Start with well-supported malicious-domain intelligence, keep the policy distinct from employee acceptable-use rules, and add nothing without a documented need.
Does a blocked lookup prove a guest tried to visit a malicious site?
No. Applications, advertisements, background services, and compromised pages can trigger lookups. Treat the event as a security signal, not proof of a person's intent.
Use a narrow Tenant policy in Veilty
In Veilty, map the guest network to a resource in the appropriate Tenant. Assign reusable baseline and enforced policies that can also serve other Tenants. The guest resource may override baseline policy for a justified narrow exception, but it cannot override enforced policy. Review aggregate results first and test one guest device before expanding. Retained activity belongs to the Tenant, is available only through permitted Tenant roles, and is end-to-end encrypted with user-held keys; the resolver still processes live DNS requests.1