Two devices see different DNS behavior when they use different resolvers, networks, cached answers, encrypted DNS or VPN paths, resource identities, or policy assignments. Compare them at the same time and on the same network, confirm each fresh query at the intended resolver, then correct the single path or scope difference that explains the result.
Keep the working and failing devices unchanged long enough to capture evidence. Randomly clearing caches, disabling privacy features, and copying settings from one device to the other can erase the useful contrast. The goal is not to make both devices identical; it is to explain the one difference that changes the DNS outcome.
Build a two-device control test
Choose one exact hostname and a five-minute window. Put both devices on the same Wi-Fi, use comparable browser sessions, and request the hostname once from each. Record device, operating system, browser or app, connection type, local time, observed result, and expected policy. If the problem only occurs on mobile data, a VPN, or another network, preserve that context as a second test instead of blending it into the control.
| Dimension | Device A | Device B |
|---|---|---|
| Network and IP family | Observed path | Observed path |
| Resolver receiving query | Resolver evidence | Resolver evidence |
| Resource or profile | Assigned scope | Assigned scope |
| Matched action | Allow, block, redirect, or log-only | Allow, block, redirect, or log-only |
| Cache and session state | Fresh or reused | Fresh or reused |
Do not infer a person from a hostname row. DNS traffic can be generated by page resources, applications, background refreshes, and prefetching as well as intentional navigation.2 Use the device comparison to explain policy behavior, not to label user intent.
Compare resolution before comparing rules
First ask whether both fresh queries reach the same resolver. A browser can use DNS over HTTPS, an operating system can apply an encrypted DNS configuration, a VPN can provide DNS, and a phone can leave Wi-Fi for cellular data. Firefox, for example, documents DNS over HTTPS modes and enterprise controls, so browser configuration is a real path variable rather than a cosmetic preference.3
- Generate one fresh lookup from each device within the recorded window.
- Confirm the intended resolver received each query and identify the transport when available.
- Compare browser Secure DNS, system DNS, VPN, security software, and manual resolver settings.
- Check both IPv4 and IPv6; a consistent IPv4 policy does not prove the IPv6 path matches.
- Repeat on the original failing network after the controlled comparison.
If only one query appears at the policy resolver, stop editing rules. Correct or intentionally document the other device's resolver path. If both arrive and receive different policy answers, continue to identity and assignment. If both receive the same DNS answer but browsers behave differently, move the investigation above DNS to connection, browser, application, or content state.
Find the identity and policy split
Resolvers need some basis for applying a device-specific policy: a resource credential, endpoint profile, network location, source address, or another supported association. Confirm how each request was classified. An unidentified device may receive a network default while a named resource receives its assigned rule set. Reused addresses and stale inventory can also associate a request with the wrong context.
For each device, write the complete effective chain: reusable baseline policy, enforced Space or Tenant policy, resource rules, permitted baseline overrides, category or catalog matches, and final action. Compare the resolver's matched decision, not screenshots of configuration pages. A newly added rule might be correct but attached to only one resource, while an enforced rule may intentionally prevent a weaker local exception.
Different policy can be correct. A shared workstation, developer device, guest network, and managed employee endpoint can have different operational needs. Preserve distinct scopes when they reflect an approved purpose. Do not flatten every resource into the most permissive policy merely to make the test results match.
Rule out cache and connection residue
DNS answers are cached according to their time-to-live behavior, and applications may keep their own caches.1 One device may hold an older allowed answer while the other makes a new blocked query. Browsers can also reuse open connections or stored page resources. Compare the DNS answer and remaining lifetime on both devices, then wait for normal expiry or use a controlled fresh context before repeating.
Avoid treating cache flushing as the first or only test. If clearing everything makes the issue disappear, you still need the earlier timestamps and answers to show whether stale state was responsible. Record the observed lifetime, when the policy changed, and when the two devices converged. That turns a one-off fix into evidence support can reuse.
DNS remains a limited signal. It can evaluate domain lookups and policy outcomes, but it cannot inspect page contents, full URLs, searches, messages, voice audio, or full browser history. When both devices receive the same answer and only one page behaves differently, use browser, application, proxy, firewall, or endpoint evidence appropriate to that layer.
Close the gap without flattening scopes
Change one proven variable: repair the resolver route, correct resource identity, assign the intended reusable policy, remove a stale rule, or wait for the documented cache lifetime. Then run the same hostname test on both devices and a representative allowed workflow. Confirm each query reaches the expected resolver, matches the intended action, and produces the expected user-visible result.
Close with a short record: affected device, hostname, window, root cause, changed scope, before-and-after decision, allowed-journey result, owner, and review date. Keep detailed activity only for the named troubleshooting window. Aggregate policy outcomes are usually enough for routine health once the difference is understood.
Two-device DNS questions
Can two devices on the same Wi-Fi use different DNS resolvers?
Yes. A browser, operating-system profile, VPN, security app, or manual setting may select another resolver even while both devices share Wi-Fi. Confirm where each fresh query arrives instead of assuming a shared access point guarantees a shared DNS path.
Does different DNS behavior mean one device is compromised?
No. Configuration, cache, network family, policy assignment, or timing usually provides a simpler explanation. Preserve the difference, compare one variable at a time, and escalate to a security investigation only when evidence such as unauthorized settings or software supports it.
Should both devices receive the same policy?
Only when their purpose and required protections are genuinely the same. Shared defaults can live in reusable baseline policy, device-specific needs can use narrower resource rules or permitted overrides, and enforced Space or Tenant policy should hold only rules that no attached resource may weaken.
Compare two Veilty resources
In Veilty, compare the two resources inside their Space or Tenant before widening policy. Reusable baseline and enforced policies apply across that scope; a resource may override baseline policy when permitted but cannot weaken enforced policy. Invitations create account membership only, and accepted members need a scoped Space or Tenant role for access. Retained activity history is scoped, end-to-end encrypted with user-held keys, and available only to permitted roles; live DNS still must be processed. Review the shortest relevant window, fix one path or assignment, then test both resources again.