An agency DNS filtering checklist should name the business risk, covered resources, client owner, resolver path, narrow policy, privacy boundary, test plan, exception route, review date, and project-end cleanup. Separate client and role needs instead of one blanket rule. Start with aggregate outcomes when uncertainty is high, enforce only justified rules, and verify normal work and a safe expected block.
The outcome is a repeatable agency rollout checklist that protects ordinary work without turning every designer, developer, administrator, contractor, and client project into the same security problem. Use it as a decision and review process, not as instructions for configuring a particular operating system, router, or DNS provider.
Write an agency risk card first
Describe one outcome before choosing rules: for example, reduce connections to known malicious domains on approved client-work resources while keeping design, development, authentication, and delivery journeys working. Name the accountable agency lead, client contact, covered work, excluded personal use, start date, review trigger, and end condition. NCSC describes protective DNS as a recursive resolver that prevents access to domains known to be malicious.1 That is a useful security layer, not a complete endpoint or identity program.
Record the boundary plainly. DNS filtering can act on a domain lookup and change its policy outcome. It cannot inspect page contents, full URLs or paths, search terms, in-app chats, voice audio, files, or full browser history. It cannot patch a laptop, assess device health, revoke an application session, or prove that a connection succeeded after DNS resolution. Assign those jobs to their owning controls.
Map clients, roles, and resources
| Agency situation | Useful boundary | Checklist decision |
|---|---|---|
| Shared malicious-domain risk | Agency team baseline | Keep it small and applicable to every covered resource |
| One client has a special requirement | Client Tenant or project profile | Do not impose it on unrelated clients |
| Designers and developers need different dependencies | Role or resource profile | Test each real toolchain before enforcement |
| Intern or short-term worker | Named temporary resource | Set an owner and removal date at approval |
| Administrative or production work | Distinct resources where risk differs | Keep higher-risk policy from spilling into ordinary work |
| Emergency personal-device use | Explicit limited work boundary | Do not claim control of personal activity outside it |
Inventory the actual resolver path as well as the intended one. Home routers, VPNs, browser secure-DNS choices, and operating-system policy can change which resolver receives a lookup. Apple documents managed DNS-over-HTTPS and DNS-over-TLS settings, while Microsoft documents Windows DNS-over-HTTPS behavior.23 Treat a resource as covered only after verification in its normal work context.
Choose the smallest defensible policy
- Name the exact risk, client or agency owner, covered resources, success measure, and end condition.
- Choose the smallest team, client, project, role, profile, or resource boundary that owns the decision.
- Begin with a short, well-understood malicious-domain baseline instead of a broad category catalog.
- Use aggregate allow and block outcomes first when classification or workflow impact is uncertain.
- Enforce only the justified block, allow, or redirect action and document who may approve a change.
- Give each exception an exact purpose, affected resources, owner, evidence, expiry, and retest requirement.
- Schedule review for staff, client, toolchain, VPN, network, browser, and project-lifecycle changes.
A temporary client project should not create a permanent agency-wide allowance. Likewise, a specialist dependency should not become a broad category exception. When a required domain is blocked, identify the winning rule and exact affected task. Narrow a permitted baseline exception to the client or resource that needs it. If enforced policy owns the decision, escalate to its owner rather than implying that a lower rule can weaken it.
Pilot the agency workflow, not a demo
Pilot with representative agency work: one ordinary staff resource, one specialist toolchain, one client-specific journey, and one remote or temporary context when those are in scope. Test sign-in, creative or development tools, client portals, file delivery, background dependencies, and an approved VPN path. Use a provider-owned harmless test domain for the expected block; never browse live malicious infrastructure.
Verify three separate facts: the resource used the intended resolver, the resolver returned the explicit policy outcome, and the complete work task succeeded or failed as expected. A browser error alone proves none of them. Caching, an alternate resolver, application behavior, or an unrelated outage can resemble a DNS block. Record rollback criteria before enforcement and stop expansion when the resolver path or required work cannot be confirmed.
Run a bounded review rhythm
Review delivery, aggregate policy outcomes, open exceptions, expiring workers, and ending projects on a predictable cadence. Open domain-level activity only for a named operational question, resource, and short interval. RFC 8932 recommends transparency around DNS data handling and minimizing retained data.4 DNS records are not page-level browsing history, but they can still reveal sensitive associations and deserve purpose-limited access.
At project close, remove project-only resources, temporary rules, obsolete allowances, and unneeded access. Confirm whether any client-owned reusable policy remains valid, who owns it, and when it will be reviewed. Retest the remaining agency baseline after cleanup. This prevents yesterday's client constraints, temporary staff, and emergency personal-device decisions from quietly shaping tomorrow's work.
Agency checklist questions
Should every agency client use the same DNS policy?
No. Keep a small agency-wide baseline only for risks that genuinely apply to every covered resource. Put client, project, role, or temporary requirements at the boundary that owns them. One client's restriction should not silently constrain unrelated work.
Can an agency review DNS activity without collecting browsing history?
DNS activity is not full browsing history: it can show domain lookups and policy outcomes, not page paths, page content, search terms, chats, audio, or user intent. Even so, domain data can be sensitive. Prefer aggregate outcomes and open detailed records only for a named resource, purpose, and short interval.
What belongs in project-end DNS cleanup?
Remove project-only resources and rules, expire temporary allowances, revoke access that is no longer needed, confirm reusable client policy still has an owner, and verify that remaining resources receive their intended baseline. Record any retained exception and its next review date.
Apply the checklist to one Veilty Tenant
In Veilty, keep agency or client resources in the team Tenant that owns the work outcome, then confirm each resource's assigned profile and actual resolver path. Reusable baseline and enforced policies can be assigned across Tenants; within a Tenant, a resource may adapt baseline policy when permitted but cannot weaken enforced policy. Put client-specific or temporary decisions at the narrowest suitable boundary.
Begin with aggregate outcomes. Retained DNS activity is Tenant-scoped, end-to-end encrypted with user-held keys, and available only through permitted Tenant roles, while the resolver necessarily processes live requests to apply policy. Pilot one representative resource, verify one ordinary work journey and one safe block, document a narrow exception route, and close project-only access and policy when the engagement ends.