A browser and other applications on the same device can resolve the same name through different DNS paths. The operating system may send a query to a router or a configured provider, while the browser sends an encrypted request to its own resolver. A VPN can introduce another resolver for some or all names. Different answers are therefore possible without a broken router or a compromised device.

When a website works in one browser but fails in another application, identify the path used for each lookup before changing settings. Record the exact hostname, time, network, and whether the VPN is connected. The answer can change with caching, policy, and geography as well as with resolver selection.

Map the DNS Layers First

The usual path starts with an application asking the operating system to resolve a name. The system may use DNS servers learned from a network connection, a manually configured address, or a VPN profile. On many home networks, the router advertises itself as the DNS server and forwards requests upstream. A device's configured DNS address therefore may identify the router rather than the final recursive resolver.

A browser can add its own layer. Its secure DNS feature may send DNS over HTTPS (DoH) directly to a provider instead of using the system's ordinary DNS query path. A browser can also have its own DNS cache. The router's DNS setting, the operating system's setting, and the browser's active resolver are therefore related but not necessarily identical.

A router change can affect devices that accept its advertised settings, while a device-specific setting applies only to that device. Neither automatically overrides an application that chooses a separate resolver. Read the active network profile's DNS addresses and the router's upstream settings separately, including any IPv4 and IPv6 entries. A manually configured device can retain a provider that differs from the one advertised by the network.

Check Browser Secure DNS Behavior

Firefox's Default Protection can use DoH where available and return to default resolvers if problems occur. It can also stop using DoH when it detects a VPN, parental controls, enterprise policies, or a network signal. Max Protection instead warns when the secure resolver cannot be used or returns no addresses; an approved domain exception can permit the system resolver. The selected protection level and any exceptions therefore matter when tracing one hostname.

By default, Chrome's automatic secure DNS mode attempts to upgrade a supported existing provider to that provider's DoH service. This can change the transport without changing the DNS provider. Automatic mode can fall back to an unencrypted lookup, while selecting a custom provider does not permit that fallback. A custom provider choice can also explain why Chrome and another application use different DNS services.

Open the browser's secure DNS settings and note the current mode, provider, status, and any managed restrictions. In Firefox, the DoH status distinguishes Active, Not active, and Off; the setting being enabled is not proof that every lookup used it. Enterprise policies can control the provider or prevent changes, and parental controls can affect availability. On a managed device, compare the configuration with the organization's intended policy before changing it.

Account for VPN and Proxy Settings

A VPN may assign DNS servers and route some name lookups through its connection. Split-tunnel and full-tunnel designs do not necessarily treat every destination or DNS suffix the same way. A company may deliberately resolve private names through its own DNS server while allowing public names through another path. The VPN application's DNS rules and the operating system's route selection both matter.

With the Mozilla VPN browser extension, a DoH resolver specified in Firefox takes priority over the resolver configured in the Mozilla VPN application. This behavior is specific to that combination. Choosing the DNS service and routing traffic through a VPN are separate decisions, so a browser can use its chosen resolver while its connection still travels through a tunnel.

When a VPN is involved, compare results with the same connection state and policy. If a private hostname only resolves through the VPN's designated DNS service, a public DoH resolver may correctly say it does not exist. That difference is expected in a split DNS design; it is not proof that the router or public resolver is faulty.

A browser proxy adds another possibility. In Chrome, an HTTP or HTTPS proxy resolves the destination hostname on the proxy side, so the browser's local DNS settings do not determine that lookup. Check whether a proxy applies to the affected address and whether a bypass rule sends it directly instead. Proxy types differ, so do not assume every proxy handles DNS the same way.

Compare the Actual Queries and Answers

Use one hostname and record type at a time. Record the browser, secure DNS mode, system DNS addresses, active network profile, VPN state, and applicable proxy. Use a diagnostic client that supports the intended resolver and transport; a normal DNS query to a server's IP address does not reproduce a DoH request to its HTTPS endpoint. Keep private company names on the organization's authorized diagnostic paths.

A records contain IPv4 addresses, while AAAA records contain IPv6 addresses, so compare matching record types. Cached DNS replies may reflect an earlier state, and content delivery networks can return different addresses according to location or time. If a private name resolves only through the VPN, check whether that matches the intended policy. If a filtering resolver refuses a name, inspect its rule instead of assuming the transport failed.

Check browser network diagnostics for the lookup that produced the result, including its time, name, and resolution source when available. Chrome's NetLog capture can record network events during a reproduced failure. An explicit query from a separate diagnostic client proves what that client received, not what the browser used earlier. If browser evidence is missing, keep the resolver choice unconfirmed rather than labeling a different answer as DNS hijacking.

Change the Setting Responsible for the Mismatch

Match the adjustment to the observed cause. Change a custom DNS provider in the browser's secure DNS settings. The router's upstream DNS setting affects clients that use the router for DNS. Internal-name failures may require an approved VPN rule or browser exception instead of replacing a public resolver for every device. Save the previous setting before an authorized change so it can be restored.

Retest the affected hostname in the same browser and VPN state, then check an unaffected public name and any required internal name. Confirm that the intended DNS and filtering policies still apply. If the result does not change, return to the recorded configuration and compare fresh diagnostic evidence before altering another layer.