A lobby or waiting-area network needs a narrow DNS policy: block well-supported malicious domains, avoid visitor identity tracking, minimize retained activity, and publish a support route. Test common visitor tasks and review false positives. Keep lobby access separate from employee and managed-device networks because DNS filtering does not create network isolation.
Define the lobby job before the rule
A public lobby network should let a visitor handle ordinary waiting-room tasks without entering the trusted office network. That may include messaging, travel changes, email, accessibility services, or a video call. Protective DNS can reduce connections to domains associated with phishing, malware, and command-and-control infrastructure. CISA describes protective DNS as analyzing DNS queries and preventing connections to known or suspected malicious infrastructure.2 That security outcome is narrower and easier to defend than trying to judge every lawful activity a visitor might choose.
Write the purpose in one sentence: “The lobby network provides temporary internet access and blocks known security threats at DNS.” Then name what is outside scope. It is not employee acceptable-use enforcement, a guest-notice drafting exercise, a policy for managed meeting-room screens, or a demo-network exception. Those situations have different owners and failure costs. A lobby rule should not quietly inherit restrictions designed for staff or company equipment.
DNS policy acts on domain lookups and policy outcomes. It cannot read a page path, webpage contents, search terms, files, in-app chats, voice audio, or full browser history. A lookup may be produced by an advertisement or background application, and an allowed lookup does not prove a connection succeeded. Network segmentation, client isolation, firewall rules, patching, and physical privacy remain separate controls.
Build a public-area boundary
Place lobby devices on a distinct visitor SSID or equivalent segment with no route to trusted internal systems. Give that segment a clearly named resolver and policy scope rather than inheriting the employee path. CISA guest-network guidance treats separation of guest traffic and telemetry as an explicit architecture concern; DNS filtering alone does not provide that separation.3 Confirm isolation and firewall behavior with the network owner before considering the policy complete.
| Decision | Good default | Keep separate |
|---|---|---|
| Scope | Lobby visitor segment | Employees, room equipment, demos, and IoT |
| Protection | Known malicious domains | Productivity and taste-based categories |
| Identity | Network or resource label | Claims about a named visitor |
| Visibility | Aggregate results first | Open-ended browsing review |
| Support | Named contact and rollback | Silent blocking with no route for help |
Decide whether DNS activity needs to be retained at all. If support and security can operate on aggregate outcomes, use those first. When detailed retained activity has a named purpose, restrict access and keep it only for the shortest useful period. Do not imply that a shared IP address or device label proves identity. Make the public notice match the actual retention and support choices, but keep the full notice work separate from this policy design.
Prove the lobby path in seven steps
- Name the lobby-network owner, security purpose, support contact, and rollback owner.
- Confirm the lobby segment cannot reach employee, operations, room-equipment, or IoT networks.
- Assign the intended resolver and a security-focused policy to the lobby scope.
- Document retention, access, deletion, and the exact wording visitors see before connecting.
- Test resolver use and a provider-owned harmless block-test domain from a phone and laptop.
- Test ordinary allowed tasks, the captive portal, accessibility tools, updates, calls, and travel sites.
- Record rollback and review the policy after network changes and on a recurring calendar.
Test from the lobby, not from an administrator laptop on the office network. A browser may use secure DNS, a device may have a VPN, and an operating-system privacy feature may select another resolver. Record these limits instead of promising universal enforcement. Never use a live malicious domain as a test. Prove that a harmless test hostname receives the expected policy response and that an ordinary allowed hostname still works.
Keep public access supportable
Give visitors a clear support route and give the owner a small triage record: time, affected lobby, visitor task, hostname if known, and observed error. First distinguish DNS from weak Wi-Fi, captive-portal failure, firewall routing, expired access, authentication, or an unavailable remote service. If DNS caused the failure, move the request into the temporary guest-exception process rather than redesigning the lobby baseline during a support call.
Review aggregate resolver health, security outcomes, support volume, stale exceptions, and mismatches between the visitor notice and live behavior. Sample every supported device class after router, DHCP, firewall, captive-portal, or resolver changes. Remove an exception when its task ends or its owner disappears. A separate demo network may justify a controlled temporary exception for a known presentation dependency; that is not a reason to weaken the everyday lobby resource.
Treat availability as part of the design. Record the previous resolver values, who can restore them, and what visitors are told during an outage. A fallback that silently removes all protection may be inappropriate, while a fail-closed design can strand people who need travel, transport, or accessibility services. Choose deliberately, test the failure behavior, and make the support desk aware of it. Also test IPv4 and IPv6 where both are offered; a correct policy on only one path can create confusing results that look intermittent.
Common mistakes are copying employee policy, treating room displays as guests, retaining details without a purpose, promising complete protection, and diagnosing every failure as DNS. Another is calling the network “safe” while guest isolation or the support route is untested. The useful standard is modest: the expected resolver is active, known threat lookups receive the intended response, ordinary visitor tasks work, and someone can restore the previous configuration.
Lobby policy questions
Should lobby and meeting-room equipment use the same DNS policy?
No. Lobby access serves unmanaged visitor devices, while room equipment is organization-managed and may need conferencing, updates, and casting services. Give them separate network and policy boundaries.
Does a lobby DNS policy identify which visitor opened a site?
No. A shared-network lookup is not reliable person-level identity, and applications can query domains in the background. DNS also cannot show page paths, contents, searches, messages, or complete browser history.
Should a public lobby block social media and streaming?
Not by default for a security-focused policy. Start with known threat categories and add a content restriction only for a documented operational or legal reason that is clearly communicated.
Keep the lobby boundary in Veilty
In Veilty, represent the lobby network as a distinct resource in the appropriate Tenant. Reuse baseline and enforced policies across Tenants: a lobby resource may override its Tenant baseline when its needs differ, but it cannot weaken an enforced Tenant policy. Review aggregate outcomes before opening retained activity or adding a narrow resource exception. Saved activity belongs to the Tenant, is end-to-end encrypted with user-held keys, and is visible only to members whose Tenant roles allow access; account membership alone grants no such access. The resolver still processes live DNS requests. Verify the result from a phone and laptop without trying to identify individual visitors.1