Explicitly allow a domain when a trusted, required service is falsely blocked, the exact hostname and owner are verified, the risk is acceptable, and the exception can be limited to affected resources. Do not override enforced protection or allow a broad wildcard merely to silence an error. Test the task, record ownership, and review the exception.
Require proof before creating an allow
An allow rule is justified when a blocklist produces the wrong outcome for a known workflow. Examples include a verified identity-provider hostname needed for sign-in, an update host used by a managed device, or a payment service incorrectly grouped with an unwanted category. The complaint alone is not enough. Confirm the resource used the intended resolver, capture the blocked hostname and matching rule, reproduce the failure, and establish that the hostname participates in the required task.
Verify ownership or service relationship through an authoritative vendor document, application support record, certificate or domain information, and current threat evidence where appropriate. A familiar-looking name is not proof. Do not allow a domain because its spelling resembles a brand, because a user says “the internet is broken,” or because several unrelated requests appeared nearby. If the exact dependency remains unknown, observe the affected resource briefly rather than creating a broad exception.
| Question | Strong evidence | Stop condition |
|---|---|---|
| What failed? | A reproducible named task | Only a vague access complaint |
| Which name? | Exact blocked hostname and rule | Only a broad parent domain |
| Who owns it? | Authoritative service relationship | Brand resemblance alone |
| Who needs it? | Specific resource or stable profile | Every account resource |
| Is risk acceptable? | Current review and accountable owner | No risk decision |
Narrow the exception across name, resource, and time
- Allow the exact hostname first; add related names only after the real workflow proves each dependency.
- Assign the rule to the one resource or purpose-based profile that needs the service.
- Name the household or team role accountable for the risk and future review.
- Record the blocked rule, business purpose, evidence, expected result, and previous behavior.
- Set an expiry date or review trigger tied to the vendor, project, update, or classification change.
- Keep a rollback step so the previous protected outcome can be restored immediately.
Wildcards multiply uncertainty. Allowing a parent and every present or future subdomain trusts more infrastructure than the diagnosed task may need. Use one only when authoritative documentation and repeated testing show that the service genuinely changes required subdomains, the ownership boundary is coherent, and exact names cannot remain reliable. Even then, narrow the resource population and review period. Convenience is not evidence that an account-wide wildcard is proportionate.
Keep mandatory protection above local overrides
Separate a normal default from a protection that resources must not weaken. A baseline can express the common starting point and permit a documented local difference. An enforced policy represents a decision that remains mandatory across its assigned household Spaces or team Tenants. If the requested domain conflicts with enforced protection, do not hide the conflict in a device allow. Escalate the risk decision to the owner of the enforced policy, with the workflow evidence and alternatives.
Also ask whether DNS is the correct control. DNS filtering can act on domain lookups and policy outcomes, but it cannot see URL paths, page contents, search terms, files, in-app chats, voice audio, or full browser history. It cannot allow one page while blocking another page on the same hostname, and it cannot grant application permissions. Use identity, browser, endpoint, application, firewall, or network controls when the exception depends on information outside DNS.
Retest the dependency and the protected outcome
Apply the allow to one representative resource. Confirm the expected DNS answer, then complete the real sign-in, payment, update, communication, or work task. Test an unaffected resource to prove its result did not change. Next, check a harmless blocked domain or provider-owned test name to confirm protective policy still works. CISA describes protective DNS as preventing connections to known or suspected malicious infrastructure; an exception should preserve that purpose rather than opening the entire category.2
Review the retained evidence cautiously. RFC 9076 explains that DNS requests can arise from embedded content, prefetching, and background software, and that linked queries may reveal sensitive patterns.3 A matching lookup does not prove a person deliberately visited a site or that an application task completed. Keep the review window short, restrict access to the responsible role, and remove unrelated detail from the decision record. Record the technical result and workflow result separately.
At review, remove the allow in a controlled window and repeat the task. If the workflow now succeeds without it, retire the exception. If it still fails, reconfirm the hostname, owner, risk, affected resources, and narrowest scope. Promote the allow into reusable baseline only when it has become a normal, acceptable requirement across the assigned Spaces or Tenants. Age alone does not turn an exception into shared policy.
Allowlist decision questions
Should an allow rule use a wildcard?
Only when verified evidence shows that a changing set of subdomains is required and the parent domain has one acceptable owner and purpose. Prefer exact hostnames whenever they work.
Can a local allow weaken enforced Space or Tenant policy?
No. A resource can override its Space or Tenant baseline for a justified local dependency, but an enforced policy remains authoritative and cannot be weakened beneath that boundary.
How often should a DNS allow exception be reviewed?
Review it at the recorded date or trigger, and sooner when the vendor, application, domain ownership, risk classification, resource population, or protected policy changes.
Govern the exception in Veilty
In Veilty, attach the narrow allow to the resource inside the household Space or team Tenant that owns the verified dependency. Reusable baseline and enforced policies may serve multiple Spaces or Tenants. A resource can override its baseline for a justified local need, but it can never weaken enforced policy. Keep the exact domain, owner, reason, evidence, test result, and review trigger with the decision instead of changing the common baseline for every resource.1
Invitations are account-scoped and do not themselves grant Space or Tenant access. After acceptance, an assigned role controls access to that boundary, its policy, and its retained activity. Saved history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted roles; the resolver still processes live DNS requests to apply policy. Review the smallest useful evidence window, then keep, narrow, or remove the allow.