A device may ignore router DNS because it has manual DNS, encrypted DNS, a VPN, a relay, mobile data, or an app-specific resolver. First prove which path the device uses on its normal network. Then correct policy at that path, clear stale state, and retest an allowed domain and a known policy outcome without weakening other devices.
Router settings are an offer, not a guarantee
A home router commonly advertises DNS servers to clients through network configuration. Google’s Public DNS documentation notes that DHCP usually supplies DNS automatically, while operating systems and devices can also hold explicit settings.1 That means a router value describes the normal path, not an unbreakable route. One phone, television, console, or browser can resolve elsewhere while its neighbors follow the router.
The difference is often intentional. Android Private DNS can use DNS over TLS; Windows supports DNS over HTTPS with choices about encrypted-query fallback; VPN and DNS-changing software can own resolution while active.12 A privacy relay, security product, work profile, or cellular connection may introduce another path. Do not label the device disobedient until you know which control is responsible.
Prove the route before fixing the rule
- Write down the device, Wi-Fi network, time, expected resolver, expected policy result, and whether mobile data or another interface is available.
- Confirm that the device is connected to the intended household network, not guest Wi-Fi, a hotspot, Ethernet with different settings, or cellular data.
- Check for a VPN, work or school management profile, private relay, security app, browser Secure DNS setting, or explicit device DNS value.
- Run a resolver-identification check and one known policy test from the same application path that showed the problem. A generic lookup in another tool may use a different resolver.
- Compare the result with a second household device on the same network. If only one differs, focus on that endpoint; if both differ, inspect the network path.
- Change one owning layer, start a fresh session, and repeat the allowed and blocked tests before widening policy.
This is a resolver-path workflow, not a platform setup guide. Menu names and managed-device behavior change, so use the device, browser, VPN, or router maker’s current documentation for the actual control. Preserve required work or school management. If the device is not yours to administer, record the mismatch and ask its owner rather than removing protections.
Sort bypass from stale state
| Observation | Likely explanation | Next useful check |
|---|---|---|
| Only one browser differs | Browser Secure DNS or cached connection | Compare a fresh session with another app |
| Every app differs only while VPN is active | VPN owns or carries DNS | Read the VPN provider’s DNS behavior |
| Wi-Fi follows policy but cellular does not | The home router is no longer on path | Treat off-network coverage separately |
| Old result changes after reconnecting | Cached answer or session state | Repeat both tests after supported cache reset |
| Several devices changed together | Network, router, or upstream change | Check advertised DNS and resolver health |
A successful page load alone does not prove DNS bypass. The name may already be cached, the application may hold an existing connection, or the service may use several hostnames. Conversely, a failed page can come from routing, certificates, captive portals, or the service itself. Use a domain with a known resolver-policy outcome and corroborate it with the narrowest available resolver evidence.
Repair only the owning layer
When a device-level resolver is deliberate and appropriate, apply the required family policy at that endpoint or document why the household network cannot govern it. When a forgotten browser or DNS-changer setting owns the path, remove it through the supported control and restore the intended automatic or managed choice. When a required VPN owns DNS, do not fight it with router changes; decide whether its protection and family policy can coexist.
Avoid router-wide experiments that weaken every device. Do not disable encrypted DNS merely to make a dashboard look consistent. Encryption protects queries on the path to a resolver, but the resolver still receives and processes them. Resolver selection, transport privacy, domain policy, and retained history are separate decisions.
Verify with a two-sided test
Test one ordinary allowed journey and one known blocked or redirected domain. Confirm the intended application still signs in and loads its dependencies. Then repeat on the device’s normal off-network path if the policy is expected to travel. Record where coverage ends: mobile data, a VPN, another encrypted resolver, or an app-specific resolver may bypass router policy. A truthful boundary is more useful than a claim of complete control.
Keep DNS evidence proportionate. DNS can show domain lookups and policy outcomes; it cannot show page contents, search terms, in-app chats, voice audio, or full browser history. RFC 9076 explains that DNS data can still reveal sensitive information and that devices move across multiple network contexts.3 Use the smallest time window needed to resolve this one mismatch.
Router-DNS troubleshooting questions
Does encrypted DNS always bypass router DNS?
No. Encrypted DNS describes transport, not necessarily a different resolver. Some systems upgrade the network-selected resolver when it supports encryption; others use a provider selected by the device, browser, app, or administrator. Confirm the destination and observed policy result rather than assuming every encrypted query left the household resolver.
Can blocking port 53 force every device to use family DNS?
No. It may affect traditional DNS, but DNS over HTTPS uses ordinary HTTPS transport, VPNs can carry DNS inside a tunnel, and mobile data leaves the home network. Forced interception can also break devices. Prefer supported device or network controls and document the remaining bypass boundary honestly.
Why does a blocked domain still open after DNS is corrected?
A cached DNS answer, an existing connection, an app cache, or a different hostname may keep the service working temporarily. Start a fresh session, wait for relevant caches to expire or clear them through supported controls, and compare a known policy-test domain with a normal allowed domain.
Keep the result in one family Space
If Veilty fits the household, represent the affected device as a resource in its family Space and verify its intended resolver path.4 Reusable baseline and enforced policies can be assigned to Spaces: a device resource may override baseline policy, but it cannot weaken enforced Space policy. Invite a caregiver to the account first, then grant the minimum Space role; an invitation alone gives no Space access. Retained activity is Space-scoped, end-to-end encrypted with user-held keys, and visible only when the role permits it, while live DNS requests still must be processed to apply policy.