Looking up DNS with dig and nslookup

Module 8: Security and troubleshooting · Reading time: 10 minutes

Learning objective: After this lesson, you'll be able to look up records with dig and nslookup, query a specific nameserver, and read the output.

Key concepts: dig, nslookup, Resolve-DnsName, +short, @server, +trace, ANSWER and AUTHORITY sections, status NOERROR, NXDOMAIN, SERVFAIL, dig -x

Why look it up yourself?

A panel shows what you've entered. What the rest of the world sees can be different: maybe another party manages the DNS, or maybe an old answer is still sitting in a cache. With a lookup tool, you ask the same question as a browser or mail server, and you see the real answer.

There are three common programmes:

No command window at hand? You can do exactly the same with an online dig tool (lesson 8.3).

Your first query with dig

Open Terminal (macOS/Linux) and type:

$ dig example.com A

The output looks like this (shortened):

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                  IN      A

;; ANSWER SECTION:
example.com.           2847    IN      A       192.0.2.10

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)

What to read:

• status: the most important word. See the table below.
• flags: ad means the resolver has verified the answer with DNSSEC (lesson 8.1).
• ANSWER SECTION: the records themselves. The columns are the same as in a zone: name, TTL, class, type, value.
• TTL (here 2847): how many seconds this answer stays in the resolver's cache. If the zone had 3600, this answer is already 753 seconds old. Ask again, and you'll see the number count down.
• SERVER: which resolver you asked. At home, that's often your router.

The three statuses you need to know

Handy variants

Only the answer with +short:

$ dig +short MX example.com
10 mail.example.com.
20 mail2.example.com.

Query another resolver or a nameserver directly with @. This is the most important trick when troubleshooting. Ask the authoritative nameserver itself, and you always get the fresh answer, without a cache:

$ dig +short NS example.com
ns1.hosting.example.
ns2.hosting.example.

$ dig +short A www.example.com @ns1.hosting.example
192.0.2.20

$ dig +short A www.example.com @9.9.9.9
192.0.2.10

Here you can see at a glance what's going on: the nameserver already gives the new address (.20), while the public resolver still has the old one in its cache (.10). You don't need to do anything, just wait until the TTL has passed (module 6).

Other types: put the type after the name.

$ dig +short TXT example.com
"v=spf1 a mx include:_spf.hosting.example ~all"
"google-site-verification=AbC123..."

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

$ dig +short CNAME shop.example.com
shops.platform.example.

Follow the whole journey with +trace. dig then does itself what a resolver does: first the root, then the TLD, then the authoritative server (lesson 1.4):

$ dig +trace example.com A
.                 518400  IN  NS  a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53
com.              172800  IN  NS  a.gtld-servers.net.
;; Received 708 bytes from 198.41.0.4#53(a.root-servers.net)
example.com.      172800  IN  NS  ns1.hosting.example.
;; Received 412 bytes from 192.5.6.30#53(a.gtld-servers.net)
example.com.      3600    IN  A   192.0.2.10
;; Received 57 bytes from 198.51.100.53#53(ns1.hosting.example)

With +trace you see which nameservers the registry is really passing on. This is handy if you're not sure whether a nameserver change has already been applied.

Seeing DNSSEC with +dnssec: you get the RRSIG signatures as well. With +cd you disable validation to see if a SERVFAIL is caused by DNSSEC.

Reverse DNS with -x (lesson 4.6):

$ dig +short -x 192.0.2.25
mail.example.com.

The same with nslookup

nslookup works on every computer. The most important forms:

C:\> nslookup example.com
Server:  router.lan
Address:  192.168.1.1

Non-authoritative answer:
Name:    example.com
Address:  192.0.2.10

C:\> nslookup -type=mx example.com
example.com    MX preference = 10, mail exchanger = mail.example.com

C:\> nslookup -type=txt _dmarc.example.com 9.9.9.9

A second address after the name (here 9.9.9.9) is the server you're querying, just like @ with dig. "Non-authoritative answer" simply means that the answer comes from a resolver and not from the authoritative nameserver: that's normal. If the name doesn't exist, nslookup says Non-existent domain, which is the same as NXDOMAIN.

Windows PowerShell: Resolve-DnsName

PS> Resolve-DnsName example.com -Type MX
PS> Resolve-DnsName _dmarc.example.com -Type TXT -Server 9.9.9.9
PS> Resolve-DnsName example.com -Type A -DnsOnly

Clearing your own cache

Does an online tool already see the new answer, but your computer doesn't yet? Then the old answer is sitting in the cache of your own computer or browser.

• Windows: ipconfig /flushdns in Command Prompt.
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder in Terminal.
• Linux with systemd-resolved: resolvectl flush-caches.
• Browser: a private window, or your phone on 4G/5G with wifi off.

You can't clear your provider's or router's cache yourself; there you just wait for the TTL.

In practice: what this looks like in a panel

Most panels don't let you run dig. So use dig alongside your panel: first check in the panel what you've entered, then use dig @<your nameserver> to check that the nameserver is really serving it, and then dig @9.9.9.9 to see whether the outside world sees it yet. My WebOké has a DNS diagnostic tool that compares the nameservers with each other; other providers have similar "DNS check" buttons.

Summary

• dig <name> <type> asks the same question as a browser or mail server; read the status first.
• NOERROR with an answer is good, NOERROR with no answer means "name exists, type doesn't", NXDOMAIN means "name doesn't exist", SERVFAIL means "no reliable answer".
• With @server you query a specific resolver or the authoritative nameserver directly; this way you see the difference between an error and a cache.
• +short, +trace, +dnssec, +cd and -x are the variants you'll need most.
• nslookup and Resolve-DnsName do the same thing on Windows.

Quiz

Exercise

Exercise Z8.2: dig and nslookup. Use dig, nslookup or Resolve-DnsName (or an online dig tool) to look up three things:

1. the status of a name that doesn't exist: bestaat-niet-dnscursus.sidn.nl;
2. the MX records of wikipedia.org, directly from one of wikipedia.org's nameservers (look that up first);
3. the TTL that a public resolver currently returns for the A record of sidn.nl (query it twice, a minute apart, and note both numbers).

Enter your answers.

Further reading

These articles describe the steps for WebOké; the commands work the same everywhere.

• DirectAdmin guide 18.7: My domain isn't working yet after a transfer or change
• How long does a nameserver or DNS change take, and what if you don't see it?
• Sending mail from your VPS and setting up reverse DNS