Keep client demos working by rehearsing on the actual visitor network, identifying the exact blocked hostname, and adding the narrowest time-bounded exception to the demo resource only. Verify sign-in, media, APIs, and security blocking before the visit, keep a rollback ready, and remove the exception after its documented review point.
Treat the demo as a known workload
A client demo is not ordinary browsing. It is a short, known workflow with an owner, device, location, dependencies, and deadline. Write the path a presenter must complete: join the network, authenticate, load the product, call APIs, stream media, share a screen, and recover from a restart. Rehearse that path using the same endpoint class, guest or presentation network, and DNS policy expected during the visit. A successful test on an employee network proves little about the visitor path.
Use an exception only after a reproducible DNS-policy failure. Do not create a permanent “demo mode,” disable all filtering for an executive visit, or copy a broad allowlist from vendor documentation. The aim is demo-safe exceptions, not an unfiltered guest network. Keep a separate connectivity option for emergencies, but secure it and test it rather than improvising a personal hotspot in front of a client.
DNS filtering can allow, block, or redirect a domain lookup. It cannot inspect page contents, URL paths, search terms, in-app chats, voice audio, or a complete browser history. It also cannot repair an expired certificate, failed login, application defect, firewall rule, or vendor outage. Start with the observed failure and resolver outcome; do not blame DNS merely because the symptom appeared in a browser.
Find the domain that actually failed
| Symptom | Check first | DNS action only if proven |
|---|---|---|
| Product does not load | Resolver, connection, certificate, and status page | Review the blocked product hostname |
| Sign-in loops | Identity redirect chain and cookies | Allow the exact required identity hostname |
| Video or assets missing | Browser network errors and vendor dependencies | Review the failed asset hostname |
| API call fails | Application response, firewall, and rate limit | Allow only a hostname blocked by policy |
Reproduce the failure and record the time, demo step, endpoint, active resolver, and policy outcome. Open retained activity only for that support question and short time window. Vendor applications often use identity, content-delivery, telemetry, and regional service domains, but that does not justify allowing every related domain or wildcard. Confirm an exact hostname using official vendor documentation and the application owner, then distinguish a required dependency from an optional tracker.
If a domain is blocked as malicious rather than by a discretionary category, pause. Check the classification source, vendor status, certificate, and ownership. Do not override credible threat intelligence to meet a meeting deadline. Escalate to security and the vendor, choose a safe fallback, or postpone the affected step. A client-facing deadline changes preparation priority, not the evidence required to weaken protective DNS.2
Build a demo-safe exception
- Assign an owner and describe the exact demo step and expected result.
- Rehearse from the actual presentation endpoint and network, then confirm the active resolver.
- Reproduce the block and isolate the exact required hostname and policy rule.
- Validate ownership and necessity through official vendor information or the service owner.
- Apply the exception only to a dedicated demo resource, or the narrowest available guest resource.
- Add a reason, approval, rollback, and review point instead of leaving an unexplained permanent rule.
- Retest the complete demo and a provider-owned harmless security block test.
Prefer a dedicated presentation endpoint or network resource because its dependencies are predictable and its exception does not change every visitor experience. Keep the normal guest baseline on that resource, then add only the demonstrated dependency. A redirect is appropriate only when the organization intentionally sends a blocked lookup to a support page and the application tolerates that behavior; it is not a substitute for allowing a required service.
Rehearse failure and rollback
Run a final rehearsal after clearing relevant application state and reconnecting to the network. Test authentication, product data, media, external integrations, screen sharing, and restart recovery. Confirm that the security baseline still blocks a provider-owned harmless test domain. Then disable or remove the exception in a controlled test and confirm the owner knows how to restore the approved state. Never use a live malicious domain for verification.
Common mistakes are testing only on office Ethernet, allowing a registrable domain with many unrelated services, confusing a firewall failure with DNS, and forgetting an exception after the visit. Another is searching broad DNS history for every vendor hostname. Begin from the failing step and timestamp instead. Keep the resulting support note: symptom, exact hostname, evidence, scope, owner, approval, test result, rollback, and review date.
After the visit, ask whether the exception belongs in the standard presentation resource, should remain temporary for a recurring client workflow, or can be removed. Recheck vendor ownership and need before making it durable. This narrow lifecycle avoids overlapping with general false-positive guidance: the focus is a rehearsed client workload, a dedicated resource, and a known business deadline.
Keep a clean rehearsal record so the next presenter can reproduce the approved path without inheriting an unexplained allowlist. A repeatable demo is the goal, not a collection of permanent vendor exceptions.
Client-demo DNS questions
Should a team allow an entire vendor domain for one demo?
Usually not. Identify the exact hostname and function first. Allow the smallest verified dependency on the demo resource, name an owner, and set a review point.
Can a DNS exception fix every broken demo?
No. Failures can come from authentication, certificates, firewalls, application bugs, rate limits, or connectivity. Diagnose before changing policy.
Should the exception apply to all guests?
No. Attach it to a dedicated demo endpoint or network resource when possible. Otherwise keep the hostname and duration narrow and retest security policy.
Scope the demo resource in Veilty
In Veilty, assign the presentation endpoint or network to a purpose-specific Tenant resource. Apply reusable baseline Tenant policy for normal protection and reserve enforced Tenant policy for rules that the resource must not override. Add only the verified demo exception to the resource baseline; never weaken an enforced rule for a meeting. Tenant roles govern access to retained Tenant activity. When that history is enabled, it is end-to-end encrypted with user-held keys, while the resolver still processes live DNS requests. Use the shortest named troubleshooting window, close the review when the question is answered, and revisit the exception after the visit.1