When something goes wrong with name resolution — a website won’t load, an email server can’t be reached, or an internal hostname isn’t working — the first thing any experienced Linux administrator reaches for is a DNS utility program. These small command-line tools let you query DNS servers directly, inspect exactly what they return, and pinpoint precisely where a problem lies.
This article covers the essential DNS utilities available on Linux: dig, nslookup, host, whois, and a few supporting tools, along with practical examples for each.
Why Learn DNS Utilities?
Applications like web browsers hide the DNS resolution process from you — you just see “page not found” without knowing whether the problem was DNS, routing, or the destination server itself. DNS utility tools let you separate these possibilities by testing name resolution independently of the application.
flowchart TD
A[Problem: Website Won't Load] --> B{Is it DNS?}
B -->|Test with dig/nslookup| C[DNS resolves correctly]
B -->|Test with dig/nslookup| D[DNS fails or wrong IP]
C --> E[Problem is likely routing/firewall/server]
D --> F[Problem is DNS configuration]Installing the Tools
Most DNS utilities come bundled in a package. On Debian/Ubuntu:
sudo apt install dnsutils -yOn RHEL/CentOS/Rocky:
sudo dnf install bind-utils -yThis installs dig, nslookup, and host.
dig — Domain Information Groper
dig is the most powerful and detailed DNS query tool available on Linux. It’s the go-to tool for professionals.
Basic Usage
dig www.example.comSample output (trimmed):
;; ANSWER SECTION:
www.example.com. 3600 IN A 93.184.216.34
;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)Querying a Specific DNS Server
dig @8.8.8.8 www.example.comQuerying Specific Record Types
dig www.example.com MX
dig www.example.com NS
dig www.example.com TXT
dig www.example.com AAAAShort Output (Just the Answer)
dig +short www.example.comReverse DNS Lookup (IP to Name)
dig -x 93.184.216.34Tracing the Full Resolution Path
dig +trace www.example.comThis shows every step of the DNS hierarchy — from root servers, to TLD servers, to the authoritative server — which is invaluable for debugging delegation issues.
nslookup — The Classic Query Tool
nslookup is older than dig and slightly less detailed, but still widely used and available on nearly every operating system (including Windows), making it useful when you need a cross-platform-familiar command.
Basic Usage
nslookup www.example.comQuerying a Specific Server
nslookup www.example.com 8.8.8.8Querying a Specific Record Type
nslookup -type=MX example.com
nslookup -type=NS example.comInteractive Mode
nslookup
> server 8.8.8.8
> set type=TXT
> example.com
> exithost — Simple and Script-Friendly
host gives clean, easily parsed output — great for shell scripts.
host www.example.comOutput:
www.example.com has address 93.184.216.34Specific Record Types
host -t MX example.com
host -t NS example.com
host -t TXT example.comReverse Lookup
host 93.184.216.34Verbose Mode
host -v www.example.comComparison Table: dig vs nslookup vs host
| Feature | dig | nslookup | host |
|---|---|---|---|
| Detail level | Very high | Medium | Low (concise) |
| Script-friendly output | Yes (+short) | No | Yes |
| Cross-platform (Windows too) | No | Yes | No |
| Trace full DNS path | Yes (+trace) | No | No |
| Interactive mode | No | Yes | No |
| Recommended for | Professionals, deep debugging | Quick familiar checks | Scripting, quick answers |
whois — Domain Registration Lookup
While not strictly a DNS resolution tool, whois is essential for DNS-related troubleshooting — it tells you who owns a domain, when it expires, and which nameservers are officially delegated to it.
sudo apt install whois -y
whois example.comSample fields you’ll see:
Domain Name: EXAMPLE.COM
Registrar: ...
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Expiration Date: ...This is especially useful when troubleshooting “the domain suddenly stopped resolving” issues — sometimes the answer is simply that the domain registration expired!
dnsmasq --test and resolvectl
If you’re running systemd-resolved, resolvectl doubles as a diagnostic tool:
resolvectl query www.example.com
resolvectl status
resolvectl statisticsresolvectl statistics shows cache hits/misses — useful for verifying local caching behavior.
Real-World Troubleshooting Walkthrough
Scenario: A user reports that internal-app.corp.local isn’t resolving on their workstation, but works fine for everyone else.
Step 1 — Check basic resolution:
dig internal-app.corp.localResult: NXDOMAIN (name doesn’t exist, according to whichever server answered).
Step 2 — Check which DNS server is being used:
cat /etc/resolv.confResult: The workstation is pointing to a public resolver (8.8.8.8) instead of the internal DNS server — a public resolver has never heard of corp.local.
Step 3 — Confirm using the correct internal server directly:
dig @10.0.0.5 internal-app.corp.localResult: Returns the correct internal IP — confirming the internal DNS server is fine, and the workstation’s misconfigured resolver settings were the actual root cause.
This is a textbook example of how using these utilities in sequence isolates a problem quickly rather than guessing.
Cisco Example: DNS Diagnostics on IOS
Cisco devices offer built-in DNS diagnostics as well:
ping www.example.com
telnet 8.8.8.8 53
show hostsshow hosts displays the router’s local DNS cache — similar in spirit to checking a Linux resolver’s cache state.
Python Example: Building a Simple DNS Diagnostic Script
import dns.resolver
import dns.reversename
def check_domain(domain):
resolver = dns.resolver.Resolver()
try:
answer = resolver.resolve(domain, 'A')
print(f"{domain} resolves to:")
for rdata in answer:
print(f" {rdata.address}")
except dns.resolver.NXDOMAIN:
print(f"{domain} does not exist (NXDOMAIN)")
except dns.resolver.NoAnswer:
print(f"{domain} has no A record")
except dns.exception.Timeout:
print(f"Query for {domain} timed out")
check_domain("www.example.com")
This kind of script is handy for monitoring dashboards that periodically verify critical hostnames are resolving correctly.
Best Practices
- Use
dig +shortin scripts — it’s the cleanest, most reliable machine-readable output. - Always test against multiple DNS servers (
@8.8.8.8,@1.1.1.1, and your internal server) to isolate whether a problem is server-specific. - Use
+tracewhen debugging delegation issues between registrars, TLDs, and authoritative servers. - Don’t forget
whois— many “DNS problems” are actually expired domain registrations. - Combine tools —
digfor deep detail,hostfor quick scripting,nslookupwhen working across mixed OS environments. - Check TTLs in
digoutput before assuming a DNS change has propagated — old cached records may still be valid.
Troubleshooting Reference Table
| Tool Output | Meaning | Next Step |
|---|---|---|
NXDOMAIN | Domain/record does not exist | Verify spelling, check zone file, check registration with whois |
SERVFAIL | DNS server had an internal error | Try a different DNS server; check server logs |
REFUSED | Server refused the query (ACL) | Check allow-query settings on the DNS server |
connection timed out | Server unreachable | Check firewall rules, port 53 (UDP/TCP) |
| Empty answer section | No record of that type exists | Query a different record type (e.g., AAAA vs A) |
Summary
DNS utility programs are the essential toolkit for any Linux user working with networks. dig gives deep, detailed insight for professionals; nslookup offers familiar cross-platform functionality; host is perfect for clean scripting output; and whois fills in the registration-level picture these tools can’t see. Mastering all four means you can diagnose almost any DNS-related problem quickly and confidently.
