digとnslookupによるDNS診断

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.