LFCS 103 🐧 DNS Client Tools — dig, host, nslookup - KandZ

⏱️ Estimated read: 9 min | |

When a name resolution fails, the first question is whether the failure is in the local configuration files (/etc/hosts, /etc/resolv.conf, /etc/nsswitch.conf) or in the DNS server itself. The tools dig, host, and nslookup exist to answer that question. They query DNS servers directly, bypassing the local resolution order, and display the raw records returned. The LFCS exam expects you to use these tools to diagnose DNS issues and interpret their output, particularly dig, which is the most capable and the recommended tool for debugging.

Key point: dig is the diagnostic tool. host is the quick lookup tool. nslookup is the legacy tool that still works but is discouraged. All three query DNS servers directly; none of them respect /etc/hosts in the same way getent hosts does.

Why these tools exist

The configuration blind spot. A failing ping google.com does not mean DNS is broken. It could mean ICMP is blocked, the network is down, or the hostname is wrong. The DNS client tools isolate the DNS layer: if dig google.com returns an answer but ping google.com fails, the problem is not DNS. Without these tools, debugging a network failure requires guessing which layer is responsible.

The caching problem. When a resolver returns an answer, it caches it for the duration of the record’s TTL (Time to Live). A recent DNS change may not be visible because the local resolver is serving a stale cached record. Querying an authoritative server directly with dig @<server> <name> bypasses the cache and shows the current state of the zone. This is the primary use case for the @ syntax.

The record type problem. A hostname can have multiple record types: A (IPv4), AAAA (IPv6), MX (mail), TXT (SPF/DKIM), NS (name server), and CNAME (alias). ping only uses A/AAAA records. dig can query any record type, which is essential for diagnosing email delivery failures (MX records) or verifying domain ownership (TXT records).

The legacy problem. nslookup was the original DNS debugging tool, and it is still installed on many systems. However, the Internet Systems Consortium (ISC), which maintains BIND, explicitly recommends against it: “Due to its arcane user interface and frequently inconsistent behavior, we do not recommend the use of nslookup. Use dig instead.” The exam may test nslookup syntax, but dig is the tool to reach for in practice.

The trade-off. dig produces verbose output that is precise but difficult to read quickly. host produces terse, one-line answers that are easy to parse in scripts. The choice depends on whether the goal is diagnosis (use dig) or a quick check (use host).

a. `dig`: the diagnostic tool

dig (Domain Information Groper) sends a DNS query and displays the complete response, including the header, question section, answer section, authority section, and additional section. The simplest invocation queries the A record for a name using the system’s configured resolver.

# Query A record
dig example.com

# Query a specific record type
dig example.com MX

# Query a specific DNS server (bypass local resolver)
dig @8.8.8.8 example.com

# Short output (just the answer)
dig +short example.com

# Reverse lookup
dig -x 8.8.8.8

The output’s status field is the first diagnostic signal. NOERROR means the query succeeded. NXDOMAIN means the domain does not exist. SERVFAIL means the server encountered an error. The ANSWER count indicates how many records were returned.

The +short flag reduces the output to the answer only, which is useful for scripting. The +noall +answer combination shows only the answer section with TTL and record type, which is a middle ground between the full output and +short.

b. `host`: the quick lookup tool

host is designed for simplicity. It converts between hostnames and IP addresses, and its output is a plain-English summary rather than a structured DNS packet.

# Forward lookup
host example.com

# Reverse lookup (automatic for IP addresses)
host 8.8.8.8

# Query a specific record type
host -t MX example.com
host -t NS example.com

# Query a specific DNS server
host example.com 8.8.8.8

The -t flag specifies the record type. Without it, host returns A, AAAA, and MX records in a single block. The -a flag is equivalent to -t ANY -v, displaying all available records for the zone. The output is script-friendly: a forward lookup returns a line like example.com has address 93.184.216.34, and a reverse lookup returns 8.8.8.8.in-addr.arpa domain name pointer dns.google.

host is the tool for quick sanity checks. It is not the tool for debugging why a record is not propagating, because it does not show the full DNS response.

c. `nslookup`: the legacy interactive tool

nslookup operates in two modes: non-interactive (a single query) and interactive (a session for multiple queries). The non-interactive form is the most common.

# Non-interactive forward lookup
nslookup example.com

# Reverse lookup
nslookup 8.8.8.8

# Query a specific server
nslookup example.com 8.8.8.8

# Query a specific record type
nslookup -type=MX example.com

The interactive mode is entered by running nslookup without arguments. From the prompt, server 8.8.8.8 changes the DNS server, and set type=MX changes the record type for subsequent queries.

The primary weakness of nslookup is that it does not display the DNS header information (status codes, flags, section counts) that dig shows. For diagnosing NXDOMAIN or SERVFAIL, this information is essential. The ISC explicitly recommends dig over nslookup for this reason.

Complete Example Session

# ============================================
# PART 1: QUERY A RECORD WITH DIG
# ============================================

dig example.com
# status: NOERROR
# ANSWER: 1
# example.com. 3600 IN A 93.184.216.34

# ============================================
# PART 2: SHORT OUTPUT
# ============================================

dig +short example.com
# 93.184.216.34

# ============================================
# PART 3: QUERY A SPECIFIC SERVER
# ============================================

dig @8.8.8.8 example.com
# Queries Google DNS instead of local resolver.

# ============================================
# PART 4: REVERSE LOOKUP
# ============================================

dig -x 8.8.8.8
# PTR record: dns.google.

# ============================================
# PART 5: QUERY MX RECORDS
# ============================================

dig example.com MX
# ANSWER: 0 (no MX records)

# ============================================
# PART 6: QUICK LOOKUP WITH HOST
# ============================================

host example.com
# example.com has address 93.184.216.34

# ============================================
# PART 7: HOST REVERSE LOOKUP
# ============================================

host 8.8.8.8
# 8.8.8.8.in-addr.arpa domain name pointer dns.google.

# ============================================
# PART 8: HOST SPECIFIC RECORD TYPE
# ============================================

host -t NS example.com
# example.com name server a.iana-servers.net.

# ============================================
# PART 9: NSLOOKUP QUERY
# ============================================

nslookup example.com
# Server: 127.0.0.53
# Address: 127.0.0.53#53
# Name: example.com
# Address: 93.184.216.34

The nine parts trace the three tools: dig full output, short output, specific server, reverse lookup, and MX query; host forward, reverse, and specific record type; and nslookup non-interactive query.

Quick Reference

dig Commands

Command	Purpose
`dig <name>`	Query A record
`dig <name> <type>`	Query specific type (MX, NS, TXT)
`dig @<server> <name>`	Query specific server
`dig +short <name>`	Answer only
`dig -x <ip>`	Reverse lookup

host Commands

Command	Purpose
`host <name>`	Forward lookup
`host <ip>`	Reverse lookup
`host -t <type> <name>`	Query specific type
`host <name> <server>`	Query specific server

nslookup Commands

Command	Purpose
`nslookup <name>`	Forward lookup
`nslookup <ip>`	Reverse lookup
`nslookup <name> <server>`	Query specific server
`nslookup -type=<type> <name>`	Query specific type

Common Record Types

Type	Purpose
A	IPv4 address
AAAA	IPv6 address
MX	Mail exchange
NS	Name server
TXT	Free-form text (SPF, DKIM)
PTR	Reverse pointer (IP to name)

Best Practices

✅ Do This:

dig +short example.com
<!-- Use for quick scripted checks -->                # ✅

dig @8.8.8.8 example.com
<!-- Bypass local cache for propagation checks -->    # ✅

dig example.com MX
<!-- Query the record type needed for diagnosis -->   # ✅

❌ Don’t Do This:

# Rely on nslookup for debugging
<!-- It does not show status codes or flags -->      # ❌

# Assume ping failure means DNS failure
<!-- ICMP may be blocked; use dig to confirm -->      # ❌

# Ignore the status field in dig output
<!-- NXDOMAIN vs NOERROR is the first diagnostic -->  # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Name resolves locally but not via dig	`/etc/hosts` override	`dig` bypasses hosts; check `getent hosts`
DNS change not visible	Resolver cache (TTL)	Query authoritative server with `@`
`NXDOMAIN` in output	Domain does not exist	Verify spelling or DNS configuration
`SERVFAIL` in output	Server error or DNSSEC failure	Check server status or DNSSEC chain
MX query returns no records	Domain has no mail server	Expected for domains without email

Real-World Examples

1. Basic dig Query

dig google.com

2. Short Answer

dig +short google.com

3. Query Specific Server

dig @1.1.1.1 google.com

4. Reverse Lookup

dig -x 8.8.8.8

5. MX Records

dig google.com MX

6. host Forward

host google.com

7. host Reverse

host 8.8.8.8

8. host MX

host -t MX google.com

9. nslookup Query

nslookup google.com

10. nslookup Specific Server

nslookup google.com 8.8.8.8

Visual

Tool Comparison

┌──────────────────────────────────────────────┐
│  dig                                         │
│  Full DNS packet, status codes, flags        │
│  Best for: debugging, propagation checks     │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  host                                        │
│  Terse, one-line answers                     │
│  Best for: quick checks, scripting           │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  nslookup                                    │
│  Legacy, interactive mode available          │
│  Best for: ad-hoc queries (discouraged)      │
└──────────────────────────────────────────────┘

DNS Query Flow

┌──────────────────────────────────────────────┐
│  dig example.com                             │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Reads /etc/resolv.conf for nameserver       │
│  (or uses @server if specified)              │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Sends UDP query to port 53                  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Displays full response                      │
│  status, ANSWER count, records, TTL          │
└──────────────────────────────────────────────┘

Summary

Item	Value
Diagnostic tool	`dig`
Quick lookup	`host`
Legacy tool	`nslookup` (discouraged)
Specific server	`@<server>` (dig), second argument (host/nslookup)
Reverse lookup	`-x` (dig), IP argument (host/nslookup)
Record type	Second argument (dig), `-t` (host), `-type` (nslookup)
Status field	`NOERROR`, `NXDOMAIN`, `SERVFAIL`
Short output	`+short` (dig)

Key takeaways:

dig is the tool for diagnosis. It shows the full DNS response, including status codes and section counts. NXDOMAIN and SERVFAIL are the first signals when something is wrong.
host is the tool for quick checks. Its output is terse and script-friendly. It is not suitable for deep debugging because it omits the DNS header.
nslookup is legacy. It still works, but the ISC recommends dig instead due to its inconsistent behavior and limited diagnostic output.
Querying a specific server bypasses the local cache. The @<server> syntax in dig (or the second argument in host/nslookup) is essential for verifying DNS propagation before the TTL expires.
A failed ping does not prove a DNS failure. The DNS client tools isolate the resolution layer; ICMP, routing, and firewall issues are separate concerns.

Remember: The three tools answer the same question—what does DNS say about this name—but they answer it with different levels of detail. dig shows everything. host shows the answer. nslookup shows a simplified answer and is kept for compatibility. Use dig when diagnosing, host when scripting, and nslookup only when it is the only tool available.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!