How can I verify which DNS resolver my device or browser is actually using for encrypted queries?
This fact-check may be outdated. Consider refreshing it to get the most current information.
Executive summary
You can check which resolver your device or browser uses by running active tests from the client that force a lookup and report which recursive resolver answered — tools exist that do this from your browser and from command-line clients (see cmdns.dev and nslookup guidance) [1] [2]. Public “global DNS check” sites can show how other resolvers see a name but do not prove which resolver your device used for an encrypted query unless the test is run from the device itself [3] [4].
1. Why “global DNS checkers” aren’t enough
Many popular sites (WhatsMyDNS, DNSChecker, DNSChecked and others) let you query dozens of public resolvers around the world to see how a domain resolves from those locations, which is useful for propagation and troubleshooting but does not directly reveal the resolver your device used for a given query [3] [5] [4]. Those services perform lookups from their own network of resolvers and show cached results; they do not run a measurement from your client to show which recursive resolver answered your encrypted (DoH/DoT) request [3] [4].
2. Browser-based and client-side tests can identify your resolver
Web pages that run tests in your browser and use crafted hostnames can infer which recursive resolver answered your DNS queries by observing where queries land; the DNS-OARC “Check My DNS” tool is expressly designed to test how your browser uses DNS by issuing specially crafted names and examining which resolver respond [1]. Command-line tools also report the default resolver your OS will use: for example, interactive nslookup prints the machine’s default DNS server and IP address, which helps determine the resolver seen by non-encrypted lookups and by applications that use the OS resolver [2].
3. Encrypted DNS adds a layer you must test for explicitly
Encrypted DNS protocols (DoH, DoT) can cause browsers or agents to bypass the system resolver and talk directly to a configured DoH/DoT provider — that means ipconfig/ifconfig output or simple nslookup results might not reflect browser behavior. Available sources describe tools that test browser-configured resolvers via crafted domains in the browser (cmdns.dev) and explain agent-level behavior where software embeds its own DoH configuration (Pro Custodibus agent uses Quad9 via DoH in some versions) [1] [6].
4. Practical steps to verify the resolver used for encrypted queries
- Run a browser-side DNS test such as the Check My DNS page from DNS-OARC while using the browser you want to test; the page issues special names and can determine how your browser’s DNS queries are processed and by which resolver [1].
- Use interactive nslookup on the device to see the OS-level default resolver; nslookup shows the default DNS server and lets you target alternate servers to compare results [2].
- Check the application/agent configuration: some agents embed their own DoH settings (Pro Custodibus agent used Quad9 via DoH by default in certain versions), so verify the app’s resolver settings rather than assuming the OS resolver applies [6].
5. What each method proves — and what it doesn’t
Browser-side tests prove what the browser actually sent and which resolver replied for those test queries [1]. Nslookup proves what the OS-level resolver is set to for traditional, unencrypted lookups but may not reveal a browser that uses built-in DoH [2] [1]. Global propagation checkers show how many external resolvers see a name and are valuable for propagation debugging, but they do not attest to which resolver your device used for an encrypted query unless the service runs a test from your client [3] [4].
6. Conflicts of interest and hidden assumptions to watch for
Tools that advertise “global checks” present results from their chosen list of remote resolvers and implicitly assume the resolver landscape is fixed; this can mislead users who equate those remote results with what their device used [3] [4]. Vendor or agent-level defaults (for example, Pro Custodibus bundling Quad9 DoH) mean software can silently override system settings — always inspect the software’s DNS/DoH configuration rather than relying solely on OS reports [6].
7. If results disagree, how to reconcile them
When browser-based tests, nslookup, and global checkers disagree: trust the test run from the client (browser or device) for that client’s behavior [1] [2]. Use the global tools to understand how other resolvers behave and whether cache/propagation explains differences [3] [4]. If an agent or app embeds its own resolver (as in the Pro Custodibus example), inspect and test that agent directly [6].
Limitations and final note: available sources describe browser-side tester pages [1], OS tools like nslookup [2], and the role of global DNS-propagation checkers [3] [4], but they do not provide a single canonical checklist that covers every OS, browser and encrypted-DNS implementation; you must combine browser tests, OS tools and application configuration checks to reach a reliable conclusion [1] [2] [6].