GICT knowledge base
How to Check DNS Server IP Address in Linux
Published
DNS servers help your Linux system find websites on the internet. They turn website names like google.com into number addresses that machines can read. Every time you open a website, your system asks a DNS server for help. Sometimes you need to know which DNS server your system is using. Maybe your internet is slow or not working at all. Finding your DNS server address can help fix these problems. This guide shows you simple ways to find your DNS server details in Linux.
What is a DNS Server?
DNS is like a phone book for the internet. You type a website name, and DNS finds its address. Without DNS, you would need to remember long number addresses for every website you visit.
Method 1: Check the resolv.conf File (Works Everywhere)
This works on all Linux systems. It’s the simplest way.
Open the terminal and type:
cat /etc/resolv.conf
You’ll see something like:
nameserver 8.8.8.8
nameserver 8.8.4.4
These numbers are your DNS servers. That’s all you need to know.
Method 2: Use the resolvectl Command
For newer Linux systems with systemd:
resolvectl status
Note: If you get “command not found” error, your system doesn’t have this command. Just use Method 1 above – it always works.
Method 3: Use nmcli Command
Most desktop Linux systems have Network Manager. Try this:
nmcli dev show | grep DNS
This shows only DNS details. Nothing extra.
Method 4: Use dig or nslookup
These commands show which DNS server they’re using:
dig google.com
Look for the “SERVER:” line at the bottom. That’s your DNS server.
Or try:
nslookup google.com
Look for the “Server:” line. That shows your DNS.
Test Your DNS
To check if DNS is working:
nslookup interserver.net
If you see numbers, your DNS works fine.
Common DNS Servers
These are DNS servers you might see:
- 8.8.8.8 – Google’s DNS
- 1.1.1.1 – Cloudflare’s DNS
- 192.168.1.1 – Your router’s DNS
Test a Different DNS
To try another DNS without changing settings:
dig @8.8.8.8 google.com
This tests Google’s DNS for that website.
Which Method to Use
Keep it simple:
- Always try first:
cat /etc/resolv.conf– works on every Linux - If you want more info:
nmcli dev show | grep DNS– for desktop Linux - Quick check:
dig google.com– shows DNS at the bottom
Don’t worry if some commands don’t work. The first method always works.
Fix DNS Problems
When internet stops working:
- Check your DNS servers with
cat /etc/resolv.conf - Test if DNS works with
nslookup google.com - Try Google’s DNS (8.8.8.8) or Cloudflare’s DNS (1.1.1.1)
Command Not Found Errors
Getting “command not found” errors? Don’t worry. Not all Linux systems have all commands. Here’s what always works:
cat /etc/resolv.conf– Available on every Linuxnslookup– Available on most Linux systemsdig– Available on most Linux systems
If one command doesn’t work, just try another. The resolv.conf file method never fails.
Conclusion
Finding DNS servers in Linux is easy. You don’t need to be an expert. Just remember: cat /etc/resolv.conf. This command works everywhere, always.
Save this guide. When internet problems happen, you’ll know what to check. DNS issues are common but easy to spot once you know how.
Don’t get confused by fancy commands. The simple way is often the best way. And in Linux, checking the resolv.conf file is as simple as it gets.
Related guides
How to Diagnose Packet Loss with mtr
Use mtr to investigate packet loss without misreading intermediate hops. Compare ICMP and TCP probes and collect useful evidence for hosting support.
NetworkingHow to Connect Two Servers Privately with WireGuard
Connect two servers with WireGuard and keep PostgreSQL on the tunnel. Verify peer traffic, private database access and denied public connections.
NetworkingEdge Computing for Web Apps: Cloudflare Workers vs Traditional Hosting
Edge computing for web apps in 2026: how Cloudflare Workers compares to traditional VPS hosting, when each wins, real cost numbers at different traffic levels, and a...
NetworkingAPI Security 101: Rate Limiting, Keys, and OAuth2 for Small Teams
API security for small teams in 2026: rate limiting strategies, API key best practices, when you actually need OAuth2, and a priority order for building it all out.
