When a client requires filtering, the agency should translate the request into named domain-level outcomes, confirm which people, resources, networks, and dates it covers, and separate DNS controls from identity, firewall, device, and content requirements. Apply the narrowest client-owned boundary, disclose it to affected workers, test real work plus a safe block, and agree on exception and evidence rules.
The outcome is a client compliance workflow the agency can actually operate: each requirement has an owner, control, scope, test, evidence limit, exception route, and end condition. This avoids two common failures at once: claiming DNS proves more than it can, and imposing a vague client restriction on every contractor and project.
Turn the client request into testable language
Ask the client to name the risk and expected domain-level result. “Block domains identified as known phishing or malware for resources working on this engagement” can be evaluated. “Make contractor browsing compliant” cannot. CISA describes protective DNS as analyzing DNS queries and preventing connections to known or suspected malicious domains.1 That supports a precise protective outcome, not a promise to inspect all internet activity.
Record the client owner, agency owner, applicable resources, locations, resolver paths, effective dates, required policy sources, expected action, availability needs, evidence, and review trigger. Ask what happens when a category conflicts with a required vendor or when a device leaves the usual network. Resolve contractual or legal ambiguity with qualified reviewers; do not let a DNS administrator invent authority from a one-line ticket.
Separate DNS duties from adjacent controls
| Client requirement | Owning control | DNS contribution |
|---|---|---|
| Block known malicious domains | Protective DNS plus layered security | Apply a domain-level block outcome |
| Restrict access to a client application | Identity and application authorization | Resolve the service, but not grant permission |
| Keep guest devices away from client systems | Network segmentation and firewall policy | No proof of network isolation |
| Inspect uploads or message content | Application, data, or endpoint control | No content visibility |
| Protect a remote work resource | Approved endpoint and resolver path | Apply policy only when that path is used |
DNS filtering can act on domain lookups and return allow, block, or redirect outcomes. It cannot read page contents, full URL paths, search terms, in-app chats, voice audio, uploaded files, or full browser history. It also cannot prove a human initiated a lookup, that a page loaded, or that another app did not use a different resolver. State those limits in the client decision record and worker notice.
Build a client policy decision record
- Write one measurable domain-level outcome and the client risk it addresses.
- List the exact client work resources and contexts included, plus explicit exclusions.
- Choose the narrowest client Tenant, profile, or supported resource boundary that owns the outcome.
- Prefer a high-confidence protective action; use a short observation period when business dependencies are uncertain.
- Disclose the policy, DNS limits, retained activity, reviewers, exception route, and removal condition to affected workers.
- Name success, failure, rollback, evidence, and approval criteria before enforcement.
- Assign a review date tied to the client engagement, policy-source change, or incident lesson.
Reserve enforced policy for client protections that an attached resource must not weaken. Keep ordinary work differences in baseline or narrower resource policy where a justified override is allowed. A request to allow one verified service should not become a client-wide category bypass. If the enforced decision is wrong, send evidence to its owner and correct that policy through the approved process.
Validate client work without dangerous tests
Test from one representative approved work resource, not an administrator's different network. Confirm the intended resolver path, then complete a real client workflow: authentication, core application use, file or API dependency as appropriate, and sign-out. Separately use only a provider-owned harmless domain intended to produce a blocked result. Never visit live phishing or malware infrastructure to demonstrate compliance.
A failed page can come from Wi-Fi, routing, firewall, certificate, application, identity, or the remote service rather than DNS. Check whether a fresh lookup reached the intended resolver and which policy outcome acted before editing rules. NCSC describes protective DNS as one layer that blocks access to known malicious domains, complementing rather than replacing other controls.2 Route each non-DNS failure to its owner.
Record the resource, assigned profile, resolver path, policy version, expected outcome, observed result, time, and reviewer. Repeat the full work journey after any exception. Test another representative network only when the approved operating context includes it. The goal is evidence for the stated client boundary, not a universal claim about every device and connection.
Report compliance with minimum visibility
Give the client evidence that matches the requirement: assigned-resource coverage, policy version, safe test result, exception inventory, review date, and aggregate outcomes. Do not provide a domain-by-domain worker narrative when a configuration and test record answers the question. RFC 8932 recommends minimizing DNS data retention and limiting access, with aggregated or pseudonymized data where feasible.3 Apply that discipline to client reporting.
Define who can ask for detail, the question it may answer, affected resource, shortest useful interval, permitted recipients, and deletion or closure condition. A domain lookup is not evidence of intent, misconduct, or content viewed. If the client demands evidence beyond the DNS boundary, pause and map that request to its proper control and authority instead of stretching DNS logs to fit it.
Client restriction answers
Should a client DNS rule apply to every agency project?
No, unless the same documented risk and authority genuinely cover every project. Prefer the client Tenant, assigned resources, or purpose-based profile that performs the work. A stricter client rule should not silently change unrelated clients, internal systems, or personal activity.
Can DNS filtering prove that no prohibited content was viewed?
No. DNS can show how a fresh domain lookup was handled on an observed resolver path. It cannot inspect page contents, searches, messages, files, or full browsing history, and it cannot prove that every application used that path. The compliance statement must stay within that evidence.
What if a required client service is blocked?
Reproduce the task, confirm the resolver and acting rule, verify the exact hostname and business need, and send that evidence to the policy owner. Grant only a permitted narrow, dated exception. If enforced policy owns the block, use an approved alternative or ask that owner to correct it rather than attempting a lower-scope bypass.
Model one client boundary in Veilty
In Veilty, use the team Tenant that owns the client engagement and attach only supported work resources that need its policy. Confirm each resource's assigned profile and resolver path. Reusable baseline and enforced policies can be assigned across Tenants. Within the client Tenant, a resource may adapt baseline policy when permitted but cannot weaken enforced policy. Account membership alone grants no Tenant access; assign the minimum relevant Tenant role separately.
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 DNS requests. Test one client resource, record the exact result and review date, and use the client's exception owner rather than widening unrelated agency policy.