DNS over HTTPS: Why Your Browser and Your DNS Lookup Tool Might Be Talking to Different Servers
Your computer's DNS settings and your browser's actual DNS resolution might be using completely different servers β DNS over HTTPS (DoH), increasingly implemented at the browser level, can bypass OS-level DNS settings entirely. Here's why DoH/DoT exist (encrypting DNS queries for privacy), why "dig shows the new record but my browser doesn't" can happen due to separate resolver caches, and how DoH interacts with network-level DNS filtering.
By sadiqbd Β· June 15, 2026
Your computer's DNS settings might say one thing, your browser might be using something completely different β and "DNS lookup" tools, browsers, and operating systems increasingly disagree about which DNS server actually answers a query, for reasons rooted in privacy rather than networking
The previous articles on this site covered DNS record types, DNS security (DNSSEC, cache poisoning), and propagation/TTLs β all assuming a relatively traditional model: a device queries a DNS resolver (configured at the OS/network level), and gets an answer. DNS over HTTPS (DoH) and DNS over TLS (DoT) complicate this picture β and understanding why they exist, and how they change "which DNS server answers," matters for troubleshooting and for understanding modern browser behavior.
Traditional DNS: plaintext, and visible to anyone on the network path
Traditional DNS queries are sent in plaintext β unencrypted β over UDP port 53 (with TCP port 53 as a fallback for larger responses). This means:
Anyone able to observe network traffic between your device and the DNS resolver β your ISP, anyone on a shared network (public WiFi), or any network intermediary β can see which domains you're looking up, even if the content of subsequent connections (HTTPS websites) is encrypted. DNS queries themselves reveal browsing patterns, even when everything "after" the DNS lookup is encrypted.
Traditional DNS is also vulnerable to manipulation by network-level intermediaries β an ISP, or a malicious actor on a shared network, could, in principle, intercept and modify DNS responses (related to the cache-poisoning/hijacking concerns covered in the previous security article) β DNSSEC addresses some of this (verifying response authenticity), but doesn't address the privacy aspect (DNSSEC-signed responses are still sent in plaintext β anyone observing the traffic can still see what's being queried, even if they can't forge responses).
DoH and DoT: encrypting the DNS query itself
DNS over TLS (DoT) β DNS queries sent over a TLS-encrypted connection, typically on port 853 (a dedicated port, distinct from standard DNS's port 53) β encrypting the query/response, preventing network-path observers from seeing which domains are being looked up.
DNS over HTTPS (DoH) β DNS queries sent as HTTPS requests, typically on port 443 (the same port as regular HTTPS web traffic) β also encrypting the query/response, with the additional characteristic that DoH traffic is indistinguishable, at the network level, from regular HTTPS traffic (since both use port 443 with TLS) β making DoH queries particularly hard for network-level observers to even identify as DNS traffic, let alone read their content.
Both DoT and DoH address the plaintext-visibility privacy concern β but via different transport mechanisms, with DoH's "looks like regular HTTPS" characteristic being particularly significant for the "can a network operator even tell DNS queries are happening, separately from web browsing" question.
The browser-level adoption: bypassing OS/network DNS settings
A significant aspect of DoH adoption: major browsers have, increasingly, implemented DoH directly within the browser β meaning the browser itself sends DNS queries via DoH to a browser-configured DoH resolver (which may be a different resolver than what's configured at the operating-system/network level) β rather than relying on the OS's traditional DNS resolution.
The practical consequence: a single device might have multiple, different "effective DNS resolvers" simultaneously β the OS-level resolver (configured via network settings β often provided by the ISP, or manually configured to a specific provider) handles DNS for most applications β while the browser, if configured to use its own DoH resolver, handles DNS for web browsing specifically via a potentially-different resolver.
Why this matters for troubleshooting: "DNS lookup" tools (including this site's, and most command-line tools β nslookup, dig, and similar) typically query the OS-level resolver (or a resolver you've explicitly specified to the tool) β *this may not be the same resolver your browser is actually using for web browsing, if the browser has its own, separate DoH configuration.
A concrete troubleshooting scenario: "I changed a DNS record, and dig/nslookup shows the new value β but my browser still shows the old site" β if the browser is using its own DoH resolver (which has its own cache, separate from the OS-level resolver's cache, and potentially with its own TTL/propagation timing) β **the command-line tool's result (querying the OS-level resolver) and the browser's actual behavior (using its own DoH resolver) can genuinely differ, during the propagation period β both results might be "correct," for their respective resolvers, but they're different resolvers, each with their own cache-expiry timing, relative to the previous article's TTL/propagation discussion.
Checking which DoH resolver a browser is using
Most major browsers provide settings (often under "privacy"/"security"-related settings sections) to view and configure the browser's DoH resolver β options typically include: "off" (use OS-level DNS, traditional behavior), "automatic"/"default" (the browser chooses a default DoH provider, potentially based on the user's existing OS-level DNS settings, attempting to find a corresponding DoH endpoint for the same provider), or *a specific, user-selected DoH provider.
For troubleshooting "browser shows different result than command-line tools" β checking the browser's DoH configuration (is it enabled? Which provider?) β and, if needed, temporarily disabling browser-level DoH (falling back to OS-level DNS) β can help isolate whether a discrepancy is due to different resolvers having different (cached) information, vs some other cause.
DoH and network-level DNS filtering/policies
Organizations/networks that implement DNS-level filtering (blocking access to certain domains via DNS β common in corporate/school network policies, parental controls, and some ISP-level services) β rely on intercepting/controlling DNS queries at the network level.
Browser-level DoH, configured to use an external DoH resolver (bypassing the network's own DNS infrastructure), can circumvent such network-level DNS filtering β since the browser's DNS queries no longer go through the network's resolver at all (instead going, encrypted, directly to the external DoH provider).
This has led some organizations/networks to specifically block known DoH endpoints (preventing browsers from reaching external DoH providers, forcing fallback to the network's own, filterable DNS) β or to configure "canary domains" (a DNS-based mechanism some browsers check, to detect "am I on a network that appears to be doing DNS-based filtering/management," and, if so, automatically disable browser-level DoH, deferring to the network's DNS) β this is an active, evolving area of interaction between privacy-oriented browser features and network-management/policy requirements, without a single, universally-settled resolution.
How to use the DNS Lookup on sadiqbd.com
- For "what does DNS currently say" β this tool, and similar command-line/web-based DNS lookup tools, query via traditional (or, depending on the specific tool's implementation, possibly DoH-based) resolution β generally providing a useful, direct answer to "what does this record currently resolve to"
- If troubleshooting browser-specific discrepancies: check the browser's own DoH configuration β a discrepancy between this tool's result and browser behavior may reflect different resolvers (and their respective, independent caches) being queried, rather than either result being "wrong"
Frequently Asked Questions
Should I enable DoH/DoT for privacy reasons? This involves trade-offs beyond pure technical considerations β DoH/DoT do address the plaintext-DNS-visibility privacy concern described above β but (a) you're placing trust in whichever DoH/DoT resolver you use β that resolver can see your DNS queries (someone has to be able to answer them) β choosing a resolver whose privacy practices/policies you're comfortable with is relevant; and (b) as discussed, DoH can interact with network-level policies (filtering, parental controls, corporate network management) in ways that might not be desired in all contexts (e.g., a parent configuring network-level filtering for a child's device, where the child's browser-level DoH, if enabled and not specifically addressed, could bypass that filtering). *This is a genuinely individual-circumstances-dependent choice, not one with a single, universally-correct answer.
Is the DNS Lookup free? Yes β completely free, no sign-up required.
Try the DNS Lookup free at sadiqbd.com β query any DNS record type for any domain instantly.