contact@linuxtpoint.com
Linuxtpoint
Candid photograph of a Linux server terminal with a soft olive-green glow against a dark slate background, conveying a calm technical atmosphere.

Step-by-step guides for system administrators — covering command-line basics, web server setup, and preparation material for technical interviews.

Browse Tutorials

Troubleshooting DNS resolution with dig and nslookup

DNS trouble often appears as a browser error, an API timeout, or one Australian website failing while others load. The useful first move is to identify which resolver answered, what status it returned and whether the requested record exists. Both dig and nslookup expose that exchange without changing server configuration.

Run tests with the exact hostname and timestamp, then compare the system resolver with another recursive server and, where possible, the zone's authoritative name servers. That sequence separates local stub configuration, recursion, delegation and application behaviour before anyone changes a firewall or resolver.

Recognising the resolver path

Start by identifying the resolver path. Read /etc/resolv.conf and, on a systemd-resolved host, run resolvectl status; 127.0.0.53 is a local stub, not the public resolver doing the lookup. Also check whether the application uses its own DNS service or DNS over HTTPS.

Keep a quick command reference nearby for syntax reminders, but preserve complete outputs. A bare nslookup result may omit the server name, response code, flags and authority section.

Choosing the right command

dig is stronger for diagnosis because it offers repeatable, script-friendly output and controls for record types, TCP, tracing and DNSSEC records. The interactive nslookup example.com command provides a quick cross-check and can target a resolver, but offers less control over query presentation.

Administrators revising for interviews can use the Linux interview questions to practise explaining stub resolvers, recursive servers and authoritative data. For fault finding, use dig as the main instrument and nslookup as a cross-check.

Reading the response

Read status before the answer. NOERROR with records means success; NOERROR with an empty answer is usually NODATA, meaning the name exists but lacks that type. NXDOMAIN says the name does not exist, while SERVFAIL or REFUSED suggests resolver policy, DNSSEC validation or server-side failure.

Inspect the flags and sections. qr marks a response, aa an authoritative answer, rd recursion desired and ra recursion available. The answer section holds requested records, the authority section explains referrals or negative answers, and additional data may contain name-server glue. TTLs show how long cached data may remain.

Name the record type explicitly with dig example.com A, AAAA, MX, NS or SOA; a missing A record does not prove a domain is down. If UDP output is truncated, repeat with +tcp. Use dig +dnssec to request signatures and flags, and delv to investigate DNSSEC validation.

Checking authoritative name servers

Find the authoritative servers with dig +short NS example.com. Parent and child zones can publish different name servers, so follow the delegation rather than querying only those returned by the local resolver. Test each directly: dig @ns1.example.com example.com A.

An authoritative reply should carry aa, while a recursive resolver usually returns ra without aa. Compare every name server and inspect glue with dig +trace example.com. Tracing may fail because outbound port 53 is blocked, so treat it as supporting evidence rather than the sole verdict.

Comparing resolvers and routes

Compare recursive resolvers with the same hostname and record type:

Then isolate transport and route:

Public resolvers may be blocked by an Australian corporate network or filtered by an ISP. If the system resolver succeeds while a public resolver times out, investigate routing or egress policy. If every resolver returns SERVFAIL, inspect DNSSEC, firewall logs and the zone configuration.

Accounting for Australian conditions

Australian conditions add useful clues. Major providers such as Telstra, Optus and Vodafone commonly supply DNS through household routers, while managed business WANs may use split-horizon resolvers. In local support chats, people often say DNS is playing up, meaning lookups are intermittent rather than the whole connection being down.

Distance matters: paths from Perth, Adelaide, Brisbane, Sydney or Melbourne to a remote authoritative server can behave differently from paths to a Sydney-hosted endpoint. Regional links, mobile data and airport or hotel Wi-Fi with captive portals may block port 53 or intercept DNS, so a hotspot comparison is a useful control.

Australian domains also need attention to delegation: widely used .com.au names and direct .au registrations sit in separate branches of the .au hierarchy. Broken parent glue or missing delegation can therefore affect an Australian domain specifically. Cloud regions in Sydney and Melbourne and global CDNs may also return location-dependent addresses, so compare each answer's IP and TTL rather than expecting one worldwide result.

A repeatable diagnostic workflow

Use a consistent runbook. Capture date -u, resolver configuration, resolvectl status, the failing hostname and a plain dig query. Repeat the same query through another resolver and directly against the authoritative name servers, preserving flags and authority data.

Change only one variable per test: resolver, record type, transport or name server. Record the timestamp because positive and negative cache entries have different TTLs. If only an internal hostname fails, check split DNS and search domains before testing its public zone.

Save the failing host's paired outputs from dig HOSTNAME and dig @1.1.1.1 HOSTNAME to the incident record, replacing HOSTNAME with the exact name from the report.