Two lookups may take different routes
When a browser opens a website, it needs an address for the hostname. A command-line DNS tool can look up that same hostname, but the two requests may not travel to the same resolver. If the browser’s secure DNS feature is enabled, it may send queries over an encrypted connection to a provider selected in its settings. A tool such as dig or nslookup usually follows its own defaults, often querying a resolver configured by the operating system or network.
Secure DNS describes how a DNS request is transported; it does not guarantee that every resolver has the same answer. Resolvers can differ in what they have cached, whether they apply filtering, and whether they can see names available only on a private network. Browser behavior also varies: some settings use secure DNS when possible but fall back to another route under certain conditions. Check the browser’s actual setting rather than assuming that an enabled-looking option governs every lookup.
Common reasons for different answers
Caching is often the simplest explanation. The browser, operating system and DNS resolver may each retain an earlier answer for a while. After a DNS record changes, one path may return the new address while another still returns the previous one. A failed lookup can also be cached, so a recently created name might work in one place and still appear missing in another.
Private naming can create a more persistent difference. A workplace network or VPN may provide a resolver that knows internal hostnames or returns private addresses for a service. A browser using an outside secure DNS provider may not receive those answers. Conversely, an organization may configure its browser or network to handle internal names separately. Local hosts-file entries and device-level filtering can introduce further differences, depending on which parts of the system each application uses.
Make sure the answers being compared are for the same question. An A lookup asks for an IPv4 address; an AAAA lookup asks for an IPv6 address. A hostname may also lead through a CNAME to another name. Meanwhile, a browser might request additional names for page resources or connect using an address it already learned. Comparing one A-record query with a browser’s overall page load does not isolate a DNS disagreement.
Compare the paths step by step
Start with the exact hostname in the browser’s address bar, without its path or query string. Note whether the browser reports that the name cannot be resolved or instead reaches a server and shows a different error. Then query that hostname for both A and AAAA records with your usual command-line tool. If the tool displays which DNS server answered, record that too. Avoid sharing screenshots or logs containing private hostnames unless you intend to disclose them.
Next, inspect the browser’s secure DNS setting and the device’s configured DNS settings, including any active VPN. They may name different providers. Where the tool supports it, compare a lookup through its default resolver with one directed to the resolver you intend to test. Change one variable at a time and keep the hostname and record type identical. If you need a public example while learning the commands, use a documentation name such as host.example rather than a private service name.
Repeat the checks after a short interval if records were recently changed. A fresh result from one resolver does not prove that every cache has expired. Clearing a browser cache may not clear its DNS cache, and clearing a device cache may not affect a remote resolver. Before changing DNS settings to fix a single failure, note the original settings so you can restore them.
Know when the problem is no longer DNS
If both paths return usable addresses but the page still fails, investigate the next stage of the connection. A connection timeout, an HTTPS certificate warning and a website error have different causes from a missing DNS answer. The browser may also choose IPv6 when a simple command-line test used IPv4, so checking both address types can help narrow down a connection failure.
The useful question is not merely “Which answer is right?” but “Which resolver answered which question, and what did the browser do next?” Matching the hostname, record type and resolver usually makes the difference understandable. Once those match, treat any remaining browser error as a separate connectivity or website problem rather than repeatedly changing DNS records.
