Knowing how to find your DNS server IP address on Linux is essential for troubleshooting name resolution, auditing network configuration, or confirming which resolver your system actually uses. This guide explains multiple reliable methods—covering traditional files like /etc/resolv.conf, systemd’s resolver (resolvectl/systemd-resolved), NetworkManager (nmcli), and command-line tools like dig and nslookup—to identify local stub resolvers, upstream DNS servers, and which server answered a query. Follow the step-by-step commands and sample outputs to quickly determine whether you are using your router, an ISP, Google, Cloudflare, or another DNS provider, and learn how to interpret stub addresses such as 127.0.0.53 so you can confidently fix DNS issues on Debian, Ubuntu, RHEL, CentOS, and other distributions.
1. Check the resolver file (/etc/resolv.conf)
The classic place to see configured DNS servers is /etc/resolv.conf. Modern systems sometimes use a local stub resolver (127.0.0.x) or symlink this file to a systemd-managed file. Viewing it quickly shows the nameserver entries your system currently references.
cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by NetworkManager # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.53 options edns0 trust-ad search example.local
This output shows a local stub resolver (127.0.0.53). When you see a loopback address, your system is using a caching service (systemd-resolved, dnsmasq, or similar). The upstream servers are not listed here when a stub resolver is used; use the systemd or NetworkManager tools below to view upstream DNS servers.
2. Use systemd's resolver (resolvectl) to see per-link DNS
On systems with systemd-resolved, use resolvectl (or systemd-resolve on older releases) to get authoritative DNS information per interface. This reveals both the current DNS server and any per-link servers.
resolvectl status | grep "DNS" DNS Servers: 192.168.1.1 8.8.8.8
The command lists DNS servers currently used by the resolver. The first address (192.168.1.1) is often a router or gateway; the second (8.8.8.8) is a public Google DNS server. Use resolvectl status <interface> to see interface-specific entries.
resolvectl status eth0
Link 2 (eth0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1 8.8.8.8 The per-link output shows “Current DNS Server” used for active queries on that interface as well as any additional “DNS Servers”. If you see multiple entries, the resolver tries them in order and may use different servers for different links.
3. If NetworkManager is managing networking, check nmcli
NetworkManager supplies DNS information to the system. Use nmcli to see what DNS servers NetworkManager set for each connection. This is useful on many desktop distributions.
nmcli dev show | grep 'IP4.DNS' IP4.DNS[1]: 192.168.1.1 IP4.DNS[2]: 1.1.1.1
Each IP4.DNS entry corresponds to a configured IPv4 DNS server for the active connection. If you have multiple network interfaces, run nmcli device show <iface> to inspect a single device.
4. Older systemd systems: systemd-resolve
On distributions that still include the legacy systemd-resolve binary, it provides similar details to resolvectl. Use it where resolvectl isn't available.
systemd-resolve --status
Global
DNS Servers: 8.8.8.8
DNSSEC NTA: 10.in-addr.arpa
Link 2 (eth0)
Current Scopes: DNS
DNS Servers: 192.168.1.1 The global and per-link sections show configured DNS servers. If the global DNS server differs from link-specific servers, systemd-resolved will choose according to routing and policy.
5. Use dig to see which DNS server answered a query
dig is a powerful DNS debugging tool. When you run a query, dig prints the resolver it used in the “SERVER” line — that tells you which DNS server responded to your request.
dig example.com ; <<>> DiG 9.16.1-Ubuntu <<>> example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; ANSWER SECTION: example.com. 299 IN A 204.45.67.203 ;; Query time: 10 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Wed Mar 3 12:34:56 UTC 2026 ;; MSG SIZE rcvd: 56
The “SERVER” line shows 192.168.1.1#53 — that is the IP and port of the DNS server that answered. If dig shows 127.0.0.53 as the SERVER, you are hitting the local stub resolver; use resolvectl or nmcli to find the upstream server it queries.
6. Find your external resolver using dig with OpenDNS
If you need to determine your public IP as seen by DNS (useful for NAT troubleshooting), query a resolver that returns your source address. The example below uses resolver1.opendns.com and the +short flag to return only the IP.
dig +short myip.opendns.com @resolver1.opendns.com 203.0.113.45
This command asks the OpenDNS resolver to return your public IP. The output is the external IP address that the DNS server sees for your machine or NAT gateway. The +short flag keeps the output concise.
7. Use nslookup to quickly see the default server
nslookup prints the default server (the resolver) and the address it is contacting. It's a simple option if you prefer a compact display.
nslookup google.com Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: google.com Address: 142.250.190.78
The “Server” and “Address” lines tell you the DNS server used for the lookup. If the server is a loopback address, combine this with resolvectl or NetworkManager queries to locate upstream servers.
8. Interpreting loopback/stub resolvers and where to look for upstream servers
Modern Linux distributions often run a local caching stub resolver (systemd-resolved, dnsmasq, or NetworkManager’s internal resolver). When /etc/resolv.conf points to 127.0.0.x, follow these steps: check resolvectl (or systemd-resolve) for upstream servers, inspect NetworkManager (nmcli) if present, and review distribution-specific files such as /run/systemd/resolve/resolv.conf or /var/run/NetworkManager/resolv.conf. If you manage DNS statically, look under /etc/network/interfaces, /etc/netplan/* (Ubuntu), or the connection files in /etc/NetworkManager/system-connections/ for configured DNS entries.
Troubleshooting tips
If DNS lookups fail or return unexpected servers, try these actions: restart the resolver service (systemctl restart systemd-resolved), flush the cache (resolvectl flush-caches), inspect NetworkManager connection profiles, and temporarily query a known public DNS (8.8.8.8 or 1.1.1.1) with dig to verify external resolution. Also verify the symlink target for /etc/resolv.conf — if it points to a runtime file managed by systemd or NetworkManager, edits to /etc/resolv.conf will not persist.
Conclusion
Determining the DNS server IP address on Linux requires understanding whether your system uses a direct resolver, a local stub, or NetworkManager/systemd-resolved. Use /etc/resolv.conf for a quick check, resolvectl/systemd-resolve for authoritative per-link information, nmcli for NetworkManager-managed connections, and dig/nslookup to see which server actually answered queries. With these tools you can identify upstream servers, verify public resolvers, and resolve DNS configuration issues across Debian, Ubuntu, RHEL, CentOS, and other distributions.