Troubleshoot DNS with dig

The dig tool asks DNS servers questions and shows exactly what they answer. Once you can read its output, most DNS problems become obvious, whether the answer is wrong, missing, or simply not updated yet.

Before you begin

• SSH access to your VPS as a sudo user, such as deploy.
• A domain you want to investigate, such as example.com.

Step 1: Install dig

dig comes from the dnsutils package on Ubuntu. Refresh the package list, install it, and check the version. The version output confirms the tool runs.

sudo apt update
sudo apt install -y dnsutils
dig -v

DiG 9.18.x-Ubuntu

Step 2: Ask a basic question

Run dig with a name and a record type. Without other options it prints a full report.

dig example.com A

The report has several parts. The header line shows the status, such as NOERROR. The ANSWER SECTION holds the records you asked for. The number in the middle column is the TTL in seconds. The footer shows which server answered and how long it took.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4821

;; ANSWER SECTION:
example.com.      3600    IN      A       203.0.113.10

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

Step 3: Get short answers

The +short option prints only the values. This is handy in scripts and when you just need to check an address.

dig +short example.com A
dig +short MX example.com
dig +short TXT example.com

These check the IP address, mail servers, and text records, such as verification strings.

Step 4: Compare your resolver with the authoritative server

Your server uses a resolver that caches answers. The authoritative nameservers hold the real records. If they differ, a cache is probably out of date. Find the nameservers first, then query one directly with @.

dig +short NS example.com
dig @ns1.example.com +short example.com A

Replace ns1.example.com with a name from the first command. If the authoritative answer is correct but your default lookup is not, wait for the TTL to expire.

Step 5: Follow the whole lookup path

The +trace option walks the lookup from the DNS root down to the authoritative server, printing each step. It is the best way to find where a broken delegation happens.

dig +trace example.com A

Step 6: Check reverse lookups

To find the name attached to an IP address, use -x:

dig -x 203.0.113.10 +short

Step 7: Read the status codes

• NOERROR with an empty answer: the name exists, but there is no record of the type you asked for.
• NXDOMAIN: the name does not exist. Check for typos and confirm the record was created.
• SERVFAIL: the server could not complete the lookup. This often points to a broken delegation or DNSSEC problem, so run +trace.
• REFUSED: the server will not answer your query, usually because it is not authoritative for that zone.

Troubleshooting

• dig: command not found. Install the package with sudo apt install -y dnsutils.
• NOERROR but no answer. The record type may be missing. Check the Lantern DNS editor for the name and type you expected.
• Different results from different servers. Propagation or caching is in progress. Compare with the authoritative query and wait for the TTL to pass.
• SERVFAIL. Run dig +trace example.com A to find the failing step, then contact LightServe support via chat or email with the output.

Next steps

Once you can read the answers, try Manage records in the Lantern DNS editor to change records yourself. If you are preparing a move, Lower your TTL before a migration shows how to speed up the change.