Skip to content
AdminKit
Talk to our team Updated

DNS resolver test: which DNS server is your device really using?

How does this check work, and what does the result tell you?

A DNS leak means your device's queries quietly go to a different resolver than configured, often because a VPN, router or malware is redirecting them. Check it in a minute by running "nslookup example.com" from a terminal and comparing the answering resolver against your settings; for a whole office or fleet, ask the Netbase team about AdminKit Protective DNS.

Part of the DNS cluster — more tools, guides and terms on dns.

Guided manual check

Run nslookup example.com (or dig example.com) and compare the resolver that answered with the DNS servers set on your device, VPN and router.

  • The Server: line in nslookup, or SERVER: in dig, is the resolver that actually answered
  • An answering resolver you never configured points to a DNS leak or a router hijack
  • Repeat it on each device and network you care about: home Wi-Fi, office LAN and VPN

Need every office, router and device checked at once? Talk to our team about having Netbase set up AdminKit Protective DNS for your sites.

Next step

Check your public IP now, or look up any domain's DNS records.

Keep this result

Copy a link to this check so you can share it or run it again later. Want a heads-up when this result changes? Talk to our team and we'll set it up for you.

Set up alerts with our team

How it works and limits

A DNS “leak” or hijack happens when your device’s queries are quietly sent to a different resolver than the one you configured — a router malware infection, a compromised DHCP setting, or (for VPN users) traffic that bypasses the tunnel are common causes. The query itself can also reveal your real location or ISP even while other traffic is otherwise private. On most home networks, the router itself is a DNS forwarder rather than a full resolver — it decides which upstream resolver every device behind it actually uses, which is exactly the layer a hijack usually targets.

Why can’t a single page request answer it?

Detecting a leak needs a request whose answer depends on which resolver asked, so a site can report “resolver X resolved this specific, disposable name.” That requires generating a unique name per visit and controlling the authoritative DNS answer for it. Showing only “here is a resolver somewhere in the path” without that uniqueness would be misleading, so this page gives you a manual check that does answer the question.

How do I check which resolver answered?

  1. Run nslookup example.com (Windows, macOS, Linux) or dig example.com (macOS, Linux). The Server: line, or SERVER: in dig’s footer, is the resolver that answered.
  2. Compare it with the DNS servers set on your device, your VPN client and your router’s admin page.
  3. If the answering resolver is one you never configured, treat it as a possible leak or hijack and check the router.

What should I do if the resolver looks wrong?

If you suspect your router’s DNS settings were changed without your knowledge — not just a leak, but an actual hijack — see is my router’s DNS hijacked? for the signs to look for and how to fix it, using the manual steps above.

If a change you made doesn’t seem to be visible from here, see DNS propagation and TTL explained for how long that can normally take, and the glossary entries for DNS over HTTPS (DoH) and DNS over TLS (DoT).

For a full rundown of the manual method above plus four other free DNS leak test tools, see best free DNS leak test tools — it compares AdminKit’s guided check with DNSLeakTest.com, ipleak.net, BrowserLeaks and Cloudflare’s 1.1.1.1 help page. Running a business and evaluating protective DNS rather than a one-off leak check? See protective DNS for UK small businesses for what NCSC’s own Protective DNS service covers, or talk to our team about having Netbase set up AdminKit Protective DNS for your sites.

Frequently asked questions

How does this page check my resolver?

It walks you through the check by hand. A single request to a web page cannot reliably show which resolver answered: detecting a leak needs an authoritative nameserver that sees which resolver actually queried a unique, one-time subdomain per visitor (the same technique dedicated DNS leak-test sites use). Showing only the address seen by one static request could miss a hijack, so this page gives you the two commands that do answer it.

What can I check manually right now?

Run `nslookup example.com` or `dig example.com` from a terminal and compare the answering resolver against your device or router's configured DNS settings — two commands available on every major OS. For a more thorough check, a dedicated DNS leak-test site uses the unique-subdomain technique described above: DNSLeakTest.com's own Extended test, for example, sends 6 rounds of 6 queries (36 total) specifically to surface every server behind a load-balanced resolver pool (dnsleaktest.com, read 2026-10-26).

What's the difference between a DNS leak and DNS hijacking?

A leak means queries unexpectedly go through a resolver you didn't intend (often bypassing a VPN tunnel) while the rest of your setup is otherwise as configured. Hijacking means something — malware, a compromised router, or an attacker — actively changed your resolver settings. The symptom you look for (an unexpected resolver) can point to either cause.

Will a VPN always prevent a DNS leak?

No — it depends on whether the VPN client forces all DNS queries through its own tunnel. Some configurations, especially with manually-set DNS servers or split tunnelling, still send DNS queries outside the VPN, which is exactly the scenario a leak test is designed to catch.

Can Netbase check resolver use across all our sites?

Yes, as a custom engagement. The Netbase team can review which resolvers every office, router and device actually uses and set up AdminKit Protective DNS for your network. Talk to our team at /contact/ with the number of sites you run.