To find out which DNS resolver you are actually using, ask your operating system which resolver it is configured to query, because that is the recursive server turning names into addresses for you. It is almost never the same thing as your own IP address, and it is often not the server you think you set. This guide shows how to read your active resolver on Windows, macOS, and Linux, how to confirm it answers correctly, and why swapping resolvers changes what you see even when nothing else about your connection changes.
Resolver versus IP address: two different things
Your public IP address is how the internet reaches you. Your DNS resolver is the server you send name lookups to so it can find addresses on your behalf. They are unrelated: your IP comes from your internet provider, while your resolver might be your router, your provider's server, or a public resolver you chose. People conflate them because both feel like network identity, but a name lookup and a return path are separate jobs. If you want to confirm the public IP side separately, the IP info tool reports the address the internet sees. For the mechanics of recursion itself, the recursive versus authoritative servers guide lays out who answers what.
Find your resolver on Windows
Open Command Prompt or PowerShell and run ipconfig /all. Look for the DNS Servers line under your active adapter; that is the resolver your system is handing lookups to. You can also run nslookup example.com and read the Server and Address lines it prints at the top, which name the resolver that answered. If the listed server is your router's LAN address, such as 192.168.1.1, your router is forwarding lookups upstream, so the resolver you truly reach is whatever the router is configured to use.
Find your resolver on macOS and Linux
On macOS, run scutil --dns in Terminal and read the nameserver entries under the resolver for your active interface; the GUI equivalent is in Network settings under the DNS tab. On Linux, the answer depends on the stack. Many desktops run systemd-resolved, so resolvectl status shows the current DNS server per link. On simpler systems, cat /etc/resolv.conf lists the nameserver lines, though on a systemd-resolved host that file often points at a local stub like 127.0.0.53 that forwards onward. On any of the three platforms, dig example.com prints a SERVER line at the bottom naming the resolver that actually answered, which is the most reliable confirmation.
Test that your resolver answers correctly
Finding the resolver is half the job; the other half is proving it returns good answers. Run a known-good lookup such as nslookup example.com or dig example.com and confirm you get an address back quickly and without a SERVFAIL or timeout. Then query the same name against a different resolver to compare. With dig you target a specific server using the at-sign syntax, for example dig @9.9.9.9 example.com or dig @1.1.1.1 example.com, and with nslookup you append the server address as a second argument. If your default resolver is slow, returns errors, or gives a stale answer while a public resolver returns the right one fast, you have found the real problem. The how to test your DNS setup guide expands on these checks.
Where to look on each platform
| Platform | Show the resolver | Confirm who answered |
|---|---|---|
| Windows | ipconfig /all (DNS Servers line) | nslookup example.com (Server line) |
| macOS | scutil --dns (nameserver entries) | dig example.com (SERVER line) |
| Linux (systemd) | resolvectl status | dig example.com (SERVER line) |
| Linux (classic) | cat /etc/resolv.conf | dig example.com (SERVER line) |
Why switching resolvers changes what you see
Different recursive resolvers can return different answers for the same name at the same moment, and that is normal. Each resolver keeps its own cache with its own TTL countdown, so one may still serve an old address minutes after another has refreshed. Some resolvers apply filtering, such as blocking known-malicious domains, so a name that resolves on one returns nothing on another. Geographically aware authoritative servers may also hand different addresses to resolvers in different regions. This is exactly why comparing two resolvers is a diagnostic: if the site loads through one resolver and not another, the issue is the resolver or its cache, not your connection or the destination server. Encrypted transports such as DNS over HTTPS can also change which resolver you reach without changing the displayed settings, covered in encrypted DNS explained.
A quick resolver checklist
- Read your active resolver with the platform command above, not from memory or an old note.
- If the resolver is your router's LAN address, find what the router forwards to upstream.
- Run a known-good lookup and confirm a fast answer with no SERVFAIL or timeout.
- Query the same name against a public resolver using the dig at-sign syntax and compare the answers.
- If the default is slow or stale while a public resolver is correct, the resolver is the fault, so switch or flush it.
To compare your resolver's answer against an authoritative view from the outside, run the hostname through the DNS lookup tool and check the public side of your connection with the IP info tool.
Frequently asked questions
How do I find which DNS resolver I am using?
Read it from the operating system: ipconfig /all on Windows, scutil --dns on macOS, and resolvectl status or /etc/resolv.conf on Linux. A dig query also prints a SERVER line naming the resolver that actually answered.
Is my DNS resolver the same as my IP address?
No. Your IP address is how the internet reaches you, while your resolver is the server you send lookups to. They come from different places and are unrelated, which is why a bad resolver can break browsing even when your connection is fine.
Why do I see a 127.0.0.53 address as my DNS server on Linux?
That is the local stub for systemd-resolved, which accepts your lookups and forwards them to the real upstream resolvers. Run resolvectl status to see the actual servers it is forwarding to per network link.
How do I test whether my DNS resolver is working?
Run a known-good lookup like dig example.com and confirm a quick answer with no SERVFAIL or timeout. Then query a public resolver with dig @1.1.1.1 example.com and compare. A difference points at your default resolver or its cache.
Does changing my resolver change my IP address?
No. Switching resolvers only changes which server answers your name lookups. Your public IP address, assigned by your internet provider, stays the same, which is why the two should be diagnosed separately.
Knowing your resolver and testing it turns vague slow-internet complaints into a specific, checkable cause. Confirm the public side with the IP info tool and the name side with the DNS lookup tool.