DNS Tools

DNS troubleshooting starts by identifying which layer is being tested. System resolver tools include local files and policy, while dig and nslookup send DNS queries and can target a specific server directly.

Testing the System Resolver

Use the normal host name-service path with:

$ getent ahosts www.example.com

On a systemd-resolved host, inspect per-link servers, search domains, and protocol state with:

$ resolvectl status
$ resolvectl query www.example.com

An application can still use a private resolver library or proxy, so reproduce through the application when outputs differ.

Querying with dig

Specify a name and record type:

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

The output identifies the responding server, status, flags, question, answer, authority, additional data, query time, and transport metadata. +short is convenient for scripts but hides evidence needed for diagnosis.

Selecting a Server

Target a resolver or authoritative server explicitly:

$ dig @192.0.2.53 www.example.com A

Compare the configured recursive resolver, a second approved resolver, and each authoritative server when isolating cache versus authority. A NOERROR status can contain no requested answer; NXDOMAIN means the queried name does not exist, while SERVFAIL means the server could not complete the query.

Checking Recursion and Authority

rd in the query requests recursion; ra in a response says the server offers it. aa means the answer is authoritative. Query an authoritative server with +norecurse to avoid confusing recursive cache with served zone data.

dig +trace NAME performs its own iterative walk starting at the root hints. It can differ from a production resolver because it bypasses that resolver's cache, forwarding, policy, DNSSEC validation, and network location.

Testing Reverse and TCP Queries

Use -x to construct a reverse PTR query:

$ dig -x 192.0.2.25

Test DNS over TCP when investigating truncation, zone transfers, or firewall differences:

$ dig +tcp @192.0.2.53 example.com SOA

Modern DNS can use UDP or TCP port 53; both should be permitted where required. A UDP answer with the truncation flag prompts compliant clients to retry through an appropriate transport.

Summary

You can now choose a DNS tool that matches the resolver layer under investigation.

1. Use getent for the configured system resolver path.
2. Use dig with explicit record types and servers.
3. Interpret status, flags, sections, and responding server together.
4. Separate recursive cache from authoritative data.
5. Test reverse queries and both required DNS transports.