How to Verify Whether a Rule Is Actually Assigned to an Endpoint

To check whether a rule reaches a device, trace the device to its endpoint identity, assigned profile or scope, effective policy, and resolver path. Then make one fresh query from that device and confirm the intended resolver records the expected rule and action. Configuration alone is not proof; an endpoint-level result is.

Assignment verification is a chain-of-custody exercise. The rule must exist, be linked to the intended scope, survive precedence, reach the endpoint identity, and be evaluated by the resolver the device actually uses. Preserve the endpoint, hostname, rule, expected action, policy revision, and short time window before changing anything.

Define the assignment chain

Write the intended path in one line: physical device to endpoint record, endpoint to profile or Space, scope to policy, policy to rule or catalog entry, and device query to resolver. Use stable identifiers where the product provides them. Display names are convenient but can be duplicated, renamed, or mistaken for a stale endpoint.

• Endpoint identity: the exact device or network resource expected to receive policy.
• Membership and scope: the profile or Space that currently owns the endpoint.
• Policy source: baseline, endpoint-specific rule, catalog attachment, or enforced protection.
• Precedence: which applicable rule wins for the test hostname and why.
• Resolver path: where a fresh query from this endpoint is actually evaluated.
• Observed result: matched rule, action, timestamp, and policy version when exposed.

Do not infer assignment from network proximity. Two devices on the same Wi-Fi can use different system settings, encrypted resolvers, VPNs, proxies, IPv6 paths, or cached answers. RFC 9076 describes how applications can select resolvers independently from the host configuration, so the actual path must be observed rather than assumed.²

Compare configured and effective policy

A configured rule is only one input. Check that it is active, linked to the intended scope, and included in the endpoint's effective policy. Then examine precedence: a more specific allow, endpoint override, redirect, enforced policy, or catalog-derived decision may win. Record the winning source instead of merely confirming that the desired rule appears somewhere in the interface.

Check timing and publication state without repeatedly toggling the rule. If the interface exposes a current policy revision or last-applied status, compare it with the endpoint result. If it does not, use a fresh query as the decisive observable. Avoid inventing a propagation delay or waiting an arbitrary number of minutes; use the product's documented state and evidence from the endpoint.

DNS policy can decide domain lookups and policy outcomes. It cannot read page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. A rule assigned to a hostname also cannot distinguish different pages or accounts behind that same hostname. Choose a test that stays at the domain layer.

Prove the rule from the endpoint

1. Choose one harmless provider-owned blocked test hostname or a domain safe for the intended policy test.
2. From the named endpoint, close reused application state and generate a fresh DNS query.
3. Confirm the query reaches the intended resolver under the expected endpoint identity.
4. Confirm the effective policy selects the intended rule source and returns the expected action.
5. Query one representative allowed hostname to ensure the endpoint has not lost normal resolution.
6. Repeat only the failing link in the chain after one narrow correction.

Test with a new lookup because DNS caches intentionally reuse answers. RFC 1034 makes caching fundamental to efficient DNS operation, and a cached result can predate the assignment being tested.¹ Closing a browser tab alone may not clear connection or DNS state. Use the smallest clean test supported by the endpoint and preserve evidence from before and after.

Never prove a block by visiting live malicious content. Use a vendor-provided test domain, controlled internal test name, or policy preview that cannot harm the tester. Also avoid using a broad activity export when one endpoint, two hostnames, and a short time range are enough. DNS queries can expose sensitive associations even though they do not show full browsing history.

Diagnose each mismatch at its owner

• Wrong endpoint identity: correct inventory or enrollment ownership before editing policy.
• Wrong profile or Space: move or link the endpoint through the authorized ownership workflow.
• Unexpected winning rule: narrow the conflicting rule or follow enforced-policy review.
• Query absent from the resolver: inspect VPN, browser secure DNS, proxy, relay, IPv6, and network path.
• Expected DNS result but app still works: inspect cached connections, alternate hostnames, or controls above DNS.

Change the owner of the broken link, not a neighboring layer. A wildcard allow cannot repair mistaken endpoint identity. A stronger block cannot reach a query sent to another resolver. Disabling encrypted DNS across a fleet does not prove which device selector conflicted. One structural correction followed by the same endpoint test produces evidence another administrator can trust.

Leave a durable assignment record

Record the endpoint identifier, profile or Space, policy source, rule, expected action, actual resolver, observed action, policy revision when available, test hostnames, time, correction, owner, and review trigger. Prefer aggregate assignment health for routine operations. Detailed activity should be opened only for a named purpose and the shortest useful window.

Rule-assignment questions

Is seeing a rule in a profile enough to prove assignment?

No. The endpoint might belong to another profile, inherit a higher-priority policy, be inactive, use a different resolver, or match a more specific rule. Compare the endpoint's effective policy and confirm the result with a fresh query from that endpoint.

Why can two devices in the same profile get different results?

They may use different resolver paths, network contexts, address families, caches, VPNs, browser secure DNS settings, or endpoint-specific overrides. Test each device directly and compare the observed resolver, effective policy revision, matched rule, and query result.

Can one DNS test prove every rule is assigned correctly?

No. One test proves one endpoint, hostname, time, resolver path, and expected action. Use representative allowed and safely blocked cases for the policy behavior you need, and repeat after material assignment or network changes.

Confirm one Veilty endpoint path

In Veilty, select one endpoint in its Space, review its endpoint filter and rule sets together with the applicable Space policy, and identify the effective action for a safe test hostname. Generate the query from that endpoint and confirm the matched result rather than assuming the configuration reached it. Veilty processes live DNS requests to answer them, while saved history is end-to-end encrypted for authorized account members. Keep the review narrow, then document the verified assignment.