Keep transparent proxying and DNS security policy as independent decisions. First let baseline and enforced Space policy decide whether the chosen site is allowed. Only then apply a narrow route for that site. Test the security decision and route separately, so a routing exception never disables malware, phishing, or content protections.
The outcome is a routing exception that preserves Space policy. An administrator should be able to explain two results without mixing them: why the domain was allowed under security policy, and why an allowed connection used a Veilty exit address. Separate evidence makes both changes easier to review and reverse.
Name two independent outcomes
Begin with two sentences. The security sentence names the domain decision: for example, “this approved site must remain allowed while known malicious domains remain blocked.” The routing sentence names the connection result: “this chosen site should see the selected Veilty exit address while unselected sites keep the device’s normal route.” If either sentence is vague, the change is not ready.
This distinction follows the actual sequence of work. DNS is a distributed naming system that returns information clients use to reach services; RFC 1034 explains its concepts and RFC 1035 defines messages and implementation.12 Security policy evaluates the lookup. A selective route affects the connection for a permitted chosen site. Sharing a workflow does not make those decisions interchangeable.
Give routing and security separate jobs
| Decision | Security filtering | Site-specific routing |
|---|---|---|
| Question | May this domain lookup proceed? | Which route should this allowed site use? |
| Preferred scope | Space policy or justified resource rule | One chosen site |
| Core evidence | Expected allow or block outcome | Exit result plus the site’s real action |
| Failure response | Review the winning policy decision | Review the chosen route and site dependencies |
| Rollback | Restore the approved policy state | Remove only the site route |
Do not edit both layers during the same troubleshooting attempt. If a lookup is blocked, a different route cannot repair the policy decision. If the lookup is allowed but the site sees the wrong address, loosening a security rule does not repair routing. One change at a time preserves a useful comparison and prevents a temporary diagnosis from becoming a permanent exception.
Preserve the Space policy boundary
Keep shared defaults in baseline Space policy and mandatory protection in enforced Space policy. A resource may need a narrow, justified difference from its baseline, but it cannot weaken enforced policy. Transparent proxying should not become a disguised allow rule. The chosen domain must pass the applicable security decision before its route matters.
Preserving that boundary also keeps incident response understandable. A protective policy owner can change a malware or phishing decision without auditing every location route. A routing owner can remove an obsolete exit choice without changing protection. Record separate reasons, owners, and review triggers even when one person currently performs both jobs.
Change routing without changing protection
- Name the exact chosen site, affected resource, expected exit result, and real signed-in action.
- Confirm that current Space policy allows the required domain for a documented reason; do not loosen enforced protection.
- Capture one expected security outcome before the route changes so the comparison has a baseline.
- Apply only the chosen-site transparent proxy rule, leaving unrelated domains and security policy unchanged.
- Test the site action, one ordinary direct site, and the independent security outcome from the affected device.
- Record the route owner, permission basis, rollback action, and a review event tied to the original need.
This is a decision workflow, not a configuration recipe. Exact connection behavior can vary with browser secure DNS, VPNs, application-specific resolvers, caches, and the site’s own hostnames. If the affected device does not use the expected DNS path, stop and identify the actual path rather than broadening policy or adding guessed domains.
Test four results, not one
A changed address alone is incomplete evidence. Verify four results from the affected device: the chosen site uses the intended route; its sign-in and core permitted action work; an unselected site keeps the normal route; and an expected security decision still holds. Temporarily removing only the route should change the route result without changing the policy result.
Keep the evidence proportional. Aggregate outcomes and a short test record are usually enough. A DNS request does not prove a person viewed or intended to visit content because applications and devices make background lookups. Retained detail should be opened only for a named troubleshooting purpose and a limited time window.
Diagnose the owning layer
- A policy block belongs to the rule owner, not the routing exception.
- A correct allow with the wrong visible address belongs to the route owner.
- A successful route with a failed sign-in may belong to the site’s account or security controls.
- A device that bypasses the expected resolver needs path diagnosis, not broader domain allowances.
- An obsolete business or household need calls for route removal, not indefinite renewal.
DNS filtering can act on domain lookups and policy outcomes. It cannot inspect page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. Transparent proxying changes a chosen site’s route; it does not add content inspection, prove user intent, hide every connection, or make the device anonymous.
Routing and security answers
Can a transparent proxy rule allow a domain blocked by enforced policy?
No. Routing should be considered only after policy permits the lookup. In Veilty, a resource can have a justified difference from baseline Space policy, but it cannot weaken enforced Space policy. Review the security decision with its owner rather than using routing to bypass it.
Should malware protection be disabled while testing a chosen-site route?
No. Leave the protective policy unchanged. Test the chosen route with a site that policy allows, and test a known policy outcome separately. Disabling protection makes the route test unrepresentative and can hide which control caused the result.
Does transparent proxying inspect what happens inside the chosen site?
No. It changes the route for the chosen site. DNS filtering can act on domain lookups and policy outcomes, but it cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history.
Review the separation in Veilty
In Veilty, review one chosen site inside the relevant Space resource. Confirm that baseline and enforced Space policies still produce the intended protection, then review the transparent proxy rule as a separate routing choice. The chosen site sees a Veilty exit address; other sites and apps keep their normal route. Verify both controls independently and remove the route when its named outcome or permission no longer applies.