Temporary DNS exceptions stay temporary when every exception has a narrow scope, named owner, stated reason, expiry condition, and verification record. Apply it only to the affected Tenant resource or household Space resource, never against enforced policy assigned to that boundary. Recheck the real workflow, preserve rollback, and remove or explicitly renew the exception at review.
Treat an exception as a loan, not a policy inheritance
An exception is a temporary transfer of risk. A payment terminal may need one newly introduced provider hostname. A developer may need a package mirror during an incident. A visiting device may need an update service until maintenance ends. None of those needs belongs automatically in the common policy for every resource. The exception should borrow only the access necessary for the stated task and return it when the task or dependency ends.
Clutter starts when an operator fixes an urgent failure by changing a reusable Space or Tenant baseline and never records why. Later reviewers see an allowance but cannot tell which resource needs it, whether the dependency still exists, or what would break if they removed it. They keep it to avoid uncertainty. Each undocumented workaround therefore makes the next cleanup harder. A small lifecycle record removes that fear and makes deletion a normal outcome.
Begin by separating baseline from enforced policy. A reusable baseline is the normal starting point for assigned Spaces or Tenants; a resource inside one of those boundaries may override that baseline for a justified local need. A reusable enforced policy is mandatory across its assigned Spaces or Tenants and cannot be weakened by a resource. If a request conflicts with enforced protection, escalate the underlying risk decision rather than disguising it as a temporary exception.
Write a seven-field exception record before changing policy
| Field | Useful entry | Weak substitute |
|---|---|---|
| Scope | Exact Space or Tenant resource | The whole account |
| Task | Business workflow that is failing | User needs access |
| Domain | Verified hostname and owner | Broad wildcard |
| Owner | Role accountable for review | IT |
| End | Date, event, or review condition | Temporary |
| Evidence | Before-and-after task result | It seemed fixed |
| Rollback | Previous result and removal step | None recorded |
The task matters more than the complaint. "The finance application cannot submit payroll" is testable; "DNS is broken" is not. Capture the time, device or resource, network context, visible error, and exact step that failed. Confirm the resource used the intended resolver before editing policy. A VPN, browser secure-DNS choice, captive portal, or operating-system setting may have selected another path. Changing a rule on a resolver that never saw the request creates clutter without solving anything.
DNS filtering acts on domain lookups and policy outcomes. It cannot inspect a URL path, page contents, search terms, files, in-app chats, voice audio, or full browser history. It also cannot prove a connection completed or identify which human caused a background lookup. RFC 9499 describes DNS as a query-response protocol.4 If the requested distinction depends on page content, an account permission, an application action, or network isolation, route it to the control that can actually observe and enforce that detail.
Prove the smallest change against the real task
- Reproduce the failure from the affected resource and record the original outcome.
- Confirm resolver, network, policy assignment, and time before interpreting activity.
- Identify the exact hostname and verify that its owner and purpose match the failing task.
- Apply the allowance only to the affected Space or Tenant resource as an override of its baseline.
- Confirm enforced policy assigned to that Space or Tenant still takes precedence and remains unchanged.
- Rerun the complete application task, not only a DNS query, and test an unaffected resource.
- Record the result, rollback, owner, and expiry condition before closing the request.
Do not test with live malicious infrastructure. Use a provider-owned harmless test domain where available, plus an ordinary allowed domain and the real business workflow. If the exact hostname cannot be established, observe narrowly rather than adding a family-wide or team-wide wildcard. CISA describes protective DNS as preventing connections to known or suspected malicious infrastructure based on DNS queries; preserving that outcome matters while resolving false positives.2
Make expiry an operational event, not a forgotten timestamp
A date alone does not clean policy. Assign a reviewer and define what happens then: remove the exception, renew it with fresh evidence, or redesign the dependency. Event-based endings can be clearer than dates. Examples include completion of a vendor visit, retirement of an old application, resolution of an incident, or migration to a new service. Put the review where the operational owner already works, such as a change record or service review, instead of relying on a separate forgotten list.
At review, first remove the allowance and repeat the task in a controlled window. If work still requires it, confirm the exact hostname, resource population, risk, and accountable role again. Promote an exception into reusable baseline only when it has become a normal need across the assigned Spaces or Tenants. Do not promote it merely because it is old. NIST CSF 2.0 emphasizes governance through defined roles, responsibilities, policies, and risk tolerances; an exception review is a small practical expression of that discipline.3
Exception-lifecycle questions
Should every temporary DNS exception have a calendar expiry date?
Use a date when the need is time-bound. For a lasting dependency, use an event or review condition, such as a vendor migration ending, with a named owner who must confirm renewal.
Can a temporary exception override Space or Tenant enforced policy?
No. A resource may override its Space or Tenant baseline where a narrow exception is justified, but enforced policy remains authoritative and cannot be weakened by that resource.
Does an allowed DNS response prove the application works?
No. Authentication, routing, certificates, application policy, or the external service may still fail. Test the actual task after confirming the DNS outcome.
Keep the exception close to its owner in Veilty
In Veilty, keep a team exception on the narrowest resource inside the appropriate Tenant. Reuse baseline and enforced policies across Tenants: a resource may override its Tenant baseline, but it cannot weaken enforced Tenant policy. Invitations are account-scoped and grant no Tenant access by themselves; after acceptance, assigned Tenant roles govern controls and retained activity. Saved history belongs to its Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted Tenant roles, while the resolver still processes live DNS requests. Start with one stale allowance: identify its owner, test its removal, and either delete it or give it an explicit review condition.1