Guests should know before connecting that the network uses DNS filtering; what risks or categories it blocks; whether DNS activity is retained; who can review it; how long it is kept; and how to report a mistaken block. Explain that DNS filtering covers domain lookups, not a complete browser history or page content.
The outcome is guest transparency without a legalistic captive-portal wall or silent observation. A visitor can make an informed choice, complete ordinary tasks, and get help when the policy is wrong. This checklist is practical governance guidance, not a statement that one notice format satisfies every jurisdiction, workplace, rental, school, or hospitality rule.
Give notice before the password
Put short notice where guests receive access: a printed card, event message, reception screen, booking note, or network sign-in page. Do not hide the first disclosure behind a link available only after connection. The IETF observes that joining a network has historically changed the device's default resolver without clearly communicating that change to the user.1 Clear notice corrects that information gap.
This guest network blocks domains associated with malware, phishing, and the listed restricted categories. We use aggregate outcomes for operations. If a required site is blocked, contact [role or channel]. Read the short privacy notice at [location] before connecting.
Adapt the example to the real policy. Do not claim that no activity is retained if troubleshooting records exist, call the network private if a third-party resolver handles queries, or promise that every harmful site is blocked. Name a role or staffed channel rather than an individual's personal contact details when the network serves many visitors.
Cover six facts, not six pages
| Fact | What to say | What to avoid |
|---|---|---|
| Purpose | We filter DNS to reduce named risks and categories | This network is completely safe |
| Scope | The policy applies while using this guest network | We protect every app everywhere |
| Activity | We retain these DNS fields for this period, or retain none | We may monitor usage |
| Access | These roles can review retained activity for these purposes | Authorized people may look |
| Sharing | Name the resolver or relevant service-provider role | No mention of outside processing |
| Help | Use this route for a mistaken block or access need | Ask the host somehow |
Keep the short notice readable, then link to a fuller statement covering collection, retention, sharing, access, security exceptions, and contact details. RFC 8932 recommends that DNS privacy services explicitly state how IP addresses and other data are collected, retained, minimized, shared, or handled as exceptions.2 A home or small organization can use the same questions to assess its resolver and explain its own choices.
Separate guest safety from surveillance
Filtering and retention are separate choices. A network can block a known malicious-domain category without preserving a person-linked history. Start with resolver health, policy version, aggregate allow or block outcomes, and guest reports. Open detail only when a named problem cannot be answered otherwise, then limit it to the guest resource and shortest useful interval. Do not reuse troubleshooting data to judge unrelated personal behavior.
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. A query can come from an advertisement, background update, embedded resource, or application prefetch. It does not prove that a guest intentionally visited a page. State those limits anywhere a reader might otherwise interpret DNS activity as surveillance-grade evidence.
Design a fair help path
- Ask for the task, affected device, approximate time, and error without requesting a broad browsing history.
- Confirm the device is on the guest network and determine the resolver and policy outcome.
- Reproduce the required task on an authorized test device when possible.
- Allow only the proven domain dependency at the guest resource or profile boundary when policy permits.
- Give a temporary exception an owner, reason, expiry or review trigger, and rollback path.
- Retest the required task and a provider-owned harmless test domain, then close temporary detailed access.
Some requests should not become DNS exceptions. A domain may conflict with a documented safety rule, a captive portal may be failing before normal DNS policy applies, or the problem may sit in an app, identity check, firewall, or content layer. Explain the decision and offer a practical alternative where appropriate. Do not weaken everyone's guest policy because one task has not yet been diagnosed.
Verify the guest experience
Test the notice and the network with a device that has no administrator context. Confirm the disclosure is visible before access, the password or sign-in flow works, an ordinary allowed task succeeds, a safe expected block produces an understandable result, and the help route reaches a responsible person. Check both a first connection and a return visit after the network forgets or renews access.
Review the disclosure when the resolver, categories, retention period, service provider, access roles, or help channel changes. Retire old QR codes and printed cards. A notice that describes last year's practices is worse than a short current one because it creates false confidence at the exact moment a guest is deciding whether to connect.
Guest network disclosure answers
Is naming every blocked domain useful notice?
Usually not. State the purpose and main categories, then provide a help route for a specific failed task. Long domain lists change, are hard to interpret, and may reveal security details without helping a guest decide whether to use the network.
Should a host retain detailed guest DNS activity?
Not by default merely because filtering is enabled. Prefer aggregate operational outcomes. If detail is necessary for a named security or troubleshooting purpose, restrict it to the shortest useful interval, limit access, disclose the practice, and remove it when the purpose ends.
Can a guest still use another DNS resolver?
Device, browser, VPN, and network behavior can change the resolver path. Do not promise complete enforcement. State the network rule and acceptable-use expectation without teaching circumvention, and verify the intended path using authorized test devices.
Scope one Veilty guest resource
In Veilty, represent guest Wi-Fi as a distinct resource inside the household Space or team Tenant that owns it. Apply the narrow guest profile there. Reusable baseline and enforced policies belong to that boundary; a resource may adapt baseline policy when permitted but cannot weaken enforced policy. Test one guest device before applying the policy to a larger event or shared location.
Use aggregate outcomes first. Retained DNS activity stays scoped to its Space or Tenant, is end-to-end encrypted with user-held keys, and is available only through permitted roles, while the resolver necessarily processes live requests. Review your real retention and access choices, publish the short notice, and verify the help path from one guest device before handing out the network password.