A coworking space should separate guest and member traffic from operations, infrastructure, and managed devices, then apply a narrow security DNS policy to each shared segment. Use network-level labels rather than inferred personal identity, publish the limits, test common work, and expire temporary access predictably. DNS filtering reduces malicious-domain exposure; it cannot provide tenant isolation or inspect content.
Build for churn between independent teams
Coworking networks differ from a small company office because occupants, devices, businesses, and work patterns change constantly. One member may run a VPN, a visitor may join for an hour, and a resident company may depend on video calls, package registries, or customer systems the operator has never seen. The useful DNS goal is shared-space safety: reduce exposure to known malicious domains without making the operator the browsing supervisor for independent businesses.
Keep this workflow distinct from security-only filtering on a conventional guest SSID. Coworking adds tenancy turnover, many independent work contexts, support handoff, and access retirement. It is also not a meeting-room equipment guide or a contractor notice. Shared displays and room controllers are operator-owned devices; contractors may have a business relationship and different notice requirements. Classify them separately.
DNS filtering acts on domain lookups and returns policy outcomes such as allow, block, or redirect. It cannot inspect URL paths, page contents, downloads, searches, in-app messages, voice calls, or full browser histories. A shared IP address or resource label does not identify a human, and a background lookup does not prove intent. Network isolation, endpoint security, identity, patching, abuse response, and physical security remain separate controls.
Map each shared-space population
Inventory populations before applying policy: day guests, recurring members, resident organizations, operator staff, printers and building systems, meeting-room equipment, and network infrastructure. Keep visitor and member traffic away from management interfaces and trusted operational devices. CISA guest-network guidance recommends separating guest traffic and telemetry from organizational traffic. Translate that principle into VLANs, SSIDs, firewall boundaries, or equivalent controls appropriate to the site; DNS policy alone cannot create isolation.3
| Population | DNS approach | Lifecycle action |
|---|---|---|
| Day guest | Shared security baseline, minimal identity | Expire access predictably |
| Recurring member | Shared baseline; exact work exception if justified | Review membership changes |
| Resident company | Separate resource only for a distinct outcome | Named company and site owners |
| Room and building devices | Operator-owned restricted resource | Inventory, patch, and retire |
| Operator staff | Organization policy, not visitor policy | Managed join and offboarding |
Use the least identity needed for operation. A segment, access cohort, or resource label is often enough to diagnose a resolver failure. Do not place a person's full name, company secrets, room booking, or membership details in DNS resource labels. If a captive portal authenticates access, document that system separately. A portal record may associate an account with a session, but DNS filtering is not identity tracking and DNS activity alone does not authenticate a member.
Choose one narrow baseline for phishing, malware, and command-and-control domains. Do not copy a resident company's acceptable-use rules to the whole building. A company that needs stricter policy can manage its endpoints or request a clearly bounded resource if the coworking operator supports it. Keep mandatory shared-space security requirements separate from optional company preferences. Do not promise that unmanaged endpoints cannot select another resolver, and do not present this workflow as personal-device management.
Run the coworking safety cycle
- Name a network owner and support owner for each site.
- Inventory populations, segments, resolver paths, captive portals, VPN interactions, and retirement triggers.
- Apply a reusable malicious-domain baseline to the member or visitor resource, not the entire site blindly.
- Decide whether activity is retained, who may access it, why, and for how long.
- Test a harmless block domain plus conferencing, authentication, payments, updates, and common developer services.
- Record exact-hostname exceptions with requester, reason, affected resource, evidence, and review date.
- Expire temporary access and review stale resources, exceptions, and support failures on a fixed cadence.
Test from a phone and laptop on each real access class. Confirm the intended resolver, then use a provider-owned safe block-test hostname; never open a live malicious destination. Test a VPN on and off where permitted and complete a captive-portal reconnect. A pass requires expected DNS behavior and successful ordinary work. If policy works only while an operator watches one device, it is not an operational result.
False positives are inevitable in a varied workspace, so make the repair path visible. Ask for the exact error, hostname, time, network, and business task without requesting unrelated browsing details. Reproduce on the same population, determine whether DNS caused the failure, and use the narrowest justified exception. Retest the task and safe threat block, then remove or renew the exception at its review date.
Measure service health, not people
Start reviews with service-level evidence: resolver availability, expected safe-block outcome, affected access classes, false-positive response time, stale resources, and exception count. Detailed retained activity should answer a named support or security question, not rank members or infer productivity. Shared NAT, caches, embedded services, and background updates make person-level conclusions especially unreliable in coworking spaces.
Common mistakes are treating the building as one trusted network, assigning one policy to every population, retaining query history indefinitely, and allowing an entire domain family for one tenant. Others include forgetting stale access codes and letting room or building devices share visitor policy. Review membership turnover, resources, retention, notices, exceptions, and rollback quarterly and after network-provider changes.
Protective DNS is useful because it can stop resolution to known malicious infrastructure before a connection proceeds, but it remains one control. CISA frames the service around preventing traffic from reaching malicious destinations. Keep ownership equally clear: the coworking operator owns the site boundary, while member companies own controls on devices and networks they manage.2
Coworking DNS questions
Should every coworking company receive a separate DNS policy?
Usually not. Separate a population only when it has a distinct, documented outcome. A shared security baseline plus narrow resource exceptions is easier to explain and maintain.
Can DNS logs identify which member made a request?
Not reliably. Shared addressing, caching, background traffic, and changing devices weaken attribution. DNS records describe lookups and outcomes, not identity or intent.
Can DNS filtering isolate coworking tenants from one another?
No. Use network segmentation, client isolation, firewall policy, and access controls for isolation. DNS filtering is an additional malicious-domain control.
Map shared resources in Veilty
In Veilty, map each justified coworking network boundary to a resource in the appropriate Tenant. Reusable baseline and enforced policies can be assigned across Tenants. A resource may override its Tenant baseline for a justified narrow exception, but it cannot override enforced policy. Verify each real access class. Retained activity belongs to its 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