Neither is universally better. Router-level DNS filtering gives broad, low-touch coverage to devices using that network, including devices that cannot run an agent. Endpoint-level filtering follows identified devices across networks and supports narrower policy. Use router coverage for the local default, endpoint coverage for mobile or differentiated devices, and test how conflicts and bypass paths resolve.
The practical outcome is a deployment choice tied to device movement, management ability, and policy differences. Do not begin with a settings screen. Inventory where each device works, whether it can carry managed DNS configuration, and whether its rules should match or differ from the network default.
Start with where policy must follow
Router-level filtering places the DNS decision at a network boundary. Devices that accept the network-provided resolver can inherit one policy without individual software. That makes it useful for a stable home, guest segment, small office, television, printer, or appliance. It also makes identity coarse: the resolver may know the source network or a mapped resource, but a shared boundary is not automatically a person.
Endpoint-level filtering places configuration or an authorized client on the device. The policy can follow a managed laptop or phone from office Wi-Fi to home broadband or another network, and device identity can support a narrower rule. The tradeoff is operational: enrollment, compatibility, updates, tamper resistance, battery or networking interactions, and recovery all need owners.
Network choice has historically influenced default resolver selection, but modern devices and applications can use encrypted DNS, VPN-provided resolution, proxies, or application-specific paths.2 Therefore neither router assignment nor endpoint configuration is proof. The winning design is the one whose real lookup path you can verify in every important context.
Compare coverage and identity
| Question | Router-level starting point | Endpoint-level starting point |
|---|---|---|
| Where does it apply? | Devices using the managed network path | The enrolled device across supported networks |
| What can it cover? | Unmanaged and agentless appliances | Managed laptops, phones, and tablets |
| How specific is policy? | Often network, segment, or mapped resource | Usually named device or profile |
| What breaks coverage? | Leaving the network or choosing another resolver | Unsupported platform, disabled client, or conflicting software |
| Who operates it? | Network administrator or household owner | Endpoint management or device owner |
Use the least complex layer that owns the job. If every device on a workshop network needs the same malicious-domain baseline, a router boundary can be sufficient. If a finance laptop needs a stricter rule everywhere it travels, endpoint policy is the clearer owner. If agentless devices need the baseline while mobile devices need continuity, a hybrid is reasonable.
Choose a deployment pattern
- Inventory devices by network context, mobility, owner, management support, and required policy difference.
- Write the common domain-level outcome and separate device-specific requirements.
- Use router-level policy for the stable local default and agentless resources that actually use its resolver.
- Use endpoint-level policy where the rule must follow an identified device or differ from its local network.
- Define precedence and expected behavior when both layers are present; avoid two unexplained policy owners.
- Name a fallback for unsupported devices and a support owner for enrollment or path failures.
Keep hybrid deployment intentional. Two identical layers may add no coverage while making wrong blocks harder to locate. On the other hand, router policy can protect an appliance that lacks endpoint support, while endpoint policy continues for a laptop away from the office. Document the distinct gap each layer closes.
Verify from the actual device
- Choose one representative device, one allowed hostname, and one safe blocked test hostname.
- Generate a fresh lookup on the managed local network and identify which resolver receives it.
- Confirm the expected resource identity, policy source, and allow, block, redirect, or log-only result.
- Move a mobile device to another expected network context and repeat the same tests.
- Check browser secure DNS, VPN, proxy, application settings, and caches when the event is absent.
- Record expected behavior, actual path, exception owner, and a date or event for review.
A cached answer or open connection can make a newly changed rule appear ineffective because the application may not issue another query. RFC 1034 describes caching as a normal DNS behavior.1 Close or refresh only the relevant test state, then create a fresh lookup. Do not restart the whole network and destroy evidence.
DNS filtering can act on domain lookups and policy outcomes. It cannot inspect page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. Endpoint placement does not turn DNS into endpoint detection, application control, file inspection, or device management. Use those tools for those jobs.
Prevent layering failures
- Do not assume DHCP-provided DNS is the only resolver path a device can use.
- Do not describe a shared network address as a reliable human identity.
- Do not install an endpoint layer merely to duplicate a verified router result.
- Do not expect router policy to follow a phone onto cellular or another Wi-Fi network.
- Do not collect broad per-device history when an aggregate result and short test window answer the question.
- Do not solve a non-DNS application failure by broadening both policy layers.
Answers for deployment choices
Does router-level DNS filtering protect devices on mobile data?
No, not merely because it protects the home or office router. When a device leaves that network, it receives another resolver path unless an endpoint, VPN, managed profile, or other authorized control continues the policy.
Can endpoint DNS filtering protect smart TVs and appliances?
Only when the device supports the required configuration or management method. Router-level policy is often the practical starting point for appliances that cannot run an agent, but administrators must still verify that the device uses the intended resolver.
What happens when router and endpoint DNS settings disagree?
The path the application actually uses determines which resolver can decide the query. Endpoint settings, browser secure DNS, VPNs, proxies, cached answers, and network controls can change that path. Trace one fresh lookup rather than assuming the stricter-looking screen wins.
Test one Veilty resource path
In Veilty, place a team device in its Tenant resource boundary, then trace that resource to its reusable baseline, any enforced policy, and the resolver that receives its fresh query. A Tenant resource may override its baseline but cannot weaken enforced policy. Retained activity belongs to the Tenant, is end-to-end encrypted with user-held keys, and is available only through permitted roles, while live DNS requests still require resolver processing. Verify one local and one off-network outcome before expanding the deployment.