DNS issues usually come down to a few things: broken connectivity, bad configs, or flaky DNS servers—any of which can stop domains from resolving properly.
Here are useful commands for diagnosing DNS issues on Linux 😎👆
Find high-res pdf ebooks with all my latest Linux infographics at https://study-notes.org/linux-ebook.html
... Read moreHey everyone! 👋 As someone who’s spent countless hours troubleshooting network hiccups, I know how frustrating a seemingly simple DNS issue can be. It often feels like the internet just… stops working! But don't worry, over time I've gathered a collection of go-to Linux commands that have saved me from countless headaches. I wanted to share them with you in a practical, easy-to-understand way, just like a friend passing on their best tech tips.
First off, when you’re facing a 'cannot resolve domain' error, the first thing I usually check is my DNS server's status. Are they even running? On modern Linux systems, systemctl status systemd-resolved or resolvectl status are my best friends. These commands give you a quick overview of your resolver's health and the DNS servers it's currently using. If systemd-resolved isn't active, that's often your culprit right there!
Next, to really dive into performing lookups, I rely heavily on dig, nslookup, and host. Each has its strengths. For a comprehensive DNS query and response, dig google.com is my absolute favorite. It shows you everything from the authoritative DNS server to the query time. If I need a quick, simple lookup, host google.com does the trick. And nslookup is a classic, great for interactive queries. I remember one time, my website wasn't resolving correctly, and dig quickly showed me an incorrect A record, which nslookup also confirmed, leading me straight to the configuration error!
Examining configurations is another crucial step. The /etc/resolv.conf file is where your system lists the DNS servers it uses. I always check this file to ensure it points to valid, reachable servers. Sometimes, NetworkManager might be managing your connections, so nmcli device show <interface name> can also reveal DNS server settings. It’s like peeking behind the curtain to see if your system is actually talking to the right DNS servers.
If DNS lookups are failing, but your DNS servers seem fine, it might be a connectivity issue. This is where analyzing network routes comes in handy. I use ip route show to check my routing table and ensure I have a path to the internet. More importantly, traceroute <DNS server IP> or mtr <DNS server IP> are invaluable. They show you every hop your packets take to reach the DNS server, helping you pinpoint exactly where connectivity breaks down. I once found a router in my home network that was silently dropping packets to my ISP's DNS, and mtr helped me identify it in minutes!
Finally, don't forget reviewing logs. Your system logs often hold clues to what went wrong. For systemd-resolved issues, journalctl -u systemd-resolved is the command to use. For more general network problems, dmesg or journalctl -k might reveal kernel-level errors related to your network interface. It's like being a detective, piecing together the story from system messages.
By systematically going through these commands, I've managed to diagnose and fix countless DNS issues on my Linux machines. It's not just about knowing the commands, but understanding what they tell you and how to interpret the output. Hopefully, these tips and my personal experiences help you conquer your next Linux DNS challenge!