Diagnostik DNS dengan dig dan nslookup

Many 'network is down' reports are really DNS failures. The host is reachable by IP, but the name will not resolve.

Linux ships tools to inspect resolution directly:

• dig — flexible, scriptable lookups
• nslookup — classic interactive tool
• host — quick one-line answers

This lesson focuses on reading their output to find the real problem.

Run dig followed by a hostname to fetch its A record.

The key part of the output is the ANSWER SECTION, which lists the resolved addresses and their TTL.

Each answer line shows: name TTL class type value.

• TTL — seconds the record may be cached
• type — A, AAAA, MX, CNAME, etc.
• value — the resolved data

Use +short to strip everything except the value.

Append the record type to look up anything besides an A record.

• dig example.com MX — mail servers
• dig example.com AAAA — IPv6
• dig example.com TXT — text records (SPF, verification)

Use @server to bypass your local resolver and ask a specific DNS server. This isolates whether your local cache is the problem.

Below queries Google Public DNS directly.

dig +trace walks from the root servers down to the authoritative server, printing each delegation step.

This reveals broken delegations or stale glue records that a normal query hides.

To map an IP back to a name, use -x. This queries the PTR record.

Missing PTR records often cause mail delivery and logging issues.

nslookup can run one-shot or interactively. In interactive mode you set type= and switch servers with server.

host gives compact output, ideal for quick checks.

• host example.com — A and AAAA
• host -t NS example.com — nameservers

The status field in the dig header is critical:

• NOERROR — resolved fine
• NXDOMAIN — name does not exist
• SERVFAIL — server failed (often DNSSEC or upstream issues)

Linux resolution settings live in /etc/resolv.conf and /etc/nsswitch.conf.

If dig works but applications fail, suspect nsswitch.conf ordering or a stale resolv.conf.

You now diagnose DNS issues directly:

• dig for flexible, scriptable lookups and +trace
• @server to isolate resolver problems
• -x for reverse lookups
• Read status codes (NOERROR/NXDOMAIN/SERVFAIL)
• Check /etc/resolv.conf and nsswitch.conf for local issues

These skills complement packet capture and firewall analysis for end-to-end troubleshooting.