Troubleshooting DNS Resolution with dig and nslookup

DNS problems can make a healthy Linux server appear offline. Web pages may fail to load, package repositories can time out, and services may report misleading connection errors. On RHEL, CentOS, Fedora, and related systems, dig and nslookup provide a fast way to separate resolver issues from routing, firewall, and application faults.

The most useful approach is to test progressively: check the local resolver, query a known public resolver, inspect the authoritative answer, and compare records such as A, AAAA, CNAME, and MX. This method is valuable for administrators in Australia, where an NBN connection, an ISP resolver, or a split-horizon corporate DNS service may each produce different results.

Command or check	Best use	What it reveals
dig example.com	Basic lookup	Status, answer, and query time
dig @1.1.1.1 example.com	Bypass local resolver	Whether the ISP or internal resolver is at fault
dig +trace example.com	Follow delegation	Where authoritative resolution fails
nslookup example.com	Quick interactive test	Resolver address and returned records
resolvectl status	Inspect host configuration	Active DNS servers and search domains

Check the local resolver first

Start with a normal lookup and request a compact response:

dig example.com
dig +short example.com

The status: NOERROR line indicates a successful DNS transaction, while NXDOMAIN means the queried name does not exist from that resolver’s perspective. An empty answer with NOERROR can mean that the record type you requested is absent, rather than that the domain is unavailable.

Inspect the resolver configuration as well:

cat /etc/resolv.conf
resolvectl status

On systems using NetworkManager or systemd-resolved, /etc/resolv.conf may be a symbolic link or generated file. Do not edit it permanently before identifying which service manages it.

Compare DNS servers directly

A local lookup can succeed or fail because of the configured nameserver. Query Cloudflare and Google directly to compare results:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
nslookup example.com 1.1.1.1

If public resolvers return an address but the default query times out, investigate the local resolver, VPN, router, or ISP service. This distinction is common on Australian home and small-office networks using Telstra, Optus, or other NBN providers, where router DNS forwarding can become stale.

A timeout does not always indicate a DNS fault. Check connectivity to the resolver and confirm that outbound UDP and TCP port 53 are permitted. Large DNS responses may use TCP, particularly when DNSSEC or many records are involved.

Read the answer section carefully

Use record-specific queries to test the name your application actually needs:

dig A www.example.com
dig AAAA www.example.com
dig CNAME www.example.com
dig MX example.com

The A record supplies an IPv4 address, while AAAA supplies IPv6. A browser may prefer IPv6 and fail even when the IPv4 result works. A CNAME points to another hostname, so follow it and verify that the target also resolves.

Pay attention to the TTL value. A recently changed address may remain cached until its time to live expires. When moving a service between Sydney and Melbourne hosting locations, administrators should lower the TTL before migration and allow existing caches to age out.

Trace delegation and authority

When recursive resolvers disagree, use:

dig +trace example.com

This follows the path from root servers to the .com nameservers and then to the domain’s authoritative servers. It can expose broken delegation, missing glue records, or an authoritative server that does not answer consistently.

Find the authoritative nameservers with:

dig NS example.com
dig SOA example.com

The SOA response identifies the primary authority, serial number, refresh settings, and responsible mailbox. If a registrar change has recently been made for an Australian .au domain, verify that the delegated nameservers match the DNS provider and that the zone has been published on every authoritative server.

Use nslookup for interactive checks

nslookup remains useful when working across older systems or when a quick interactive session is preferred:

nslookup
> server 8.8.8.8
> set type=AAAA
> example.com
> exit

The interactive mode makes it easy to switch record types and resolvers without repeating a full command. It also displays the server used for each query, which helps identify an unexpected corporate DNS appliance or VPN-provided resolver.

For reverse DNS, query the address rather than the hostname:

nslookup 203.0.113.25
dig -x 203.0.113.25

Reverse records matter for mail delivery, audit logs, and some security controls. They are separate from forward DNS, so a working hostname lookup does not guarantee a correct PTR record.

Check DNS alongside services

If DNS resolves correctly but a website remains unavailable, test the resulting address and service port:

curl -I https://example.com
nc -vz example.com 443

For Nginx hosts, confirm that the server_name matches the requested hostname and review the relevant access and error logs. The Nginx administration guide provides useful context for separating virtual-host configuration from DNS behaviour.

Application teams can also test the exact API hostname used by mobile clients. An Android project using Jetpack Compose basics may display a generic network error when the underlying cause is an incorrect API record, expired certificate, or unreachable IPv6 address.

Prevent recurring resolution faults

Good DNS troubleshooting includes preserving evidence before changing settings. Capture the command, resolver address, timestamp, response status, and returned records. Queries run at 09:00 AEST may differ from those run later because of caching or provider failover.

Useful operational habits include:

• Test both A and AAAA records for public services.
• Compare the default resolver with at least one trusted external resolver.
• Record TTL values before and after DNS changes.
• Keep zone, resolver, and network configuration backups; an rsync backup procedure can protect important RHEL configuration files.
• Check firewall logs when queries time out rather than return an error.

When a lookup fails, begin with dig, compare resolvers, inspect delegation with +trace, and then test the application port. That sequence turns an unclear “DNS issue” into a specific resolver, record, delegation, or service fault that can be fixed with confidence.