DNS lookup on the command line: nslookup, dig and PowerShell

· 4 min read

An online tool is quick, but sometimes you want to know what your own machine sees, which resolver answers, or whether the authoritative name server already serves the new value. This guide covers the three tools that ship with every system, with the commands you actually need day to day with client domains.

nslookup on Windows

nslookup has shipped with every Windows for decades and answers most questions. Without further arguments it asks the resolver from the network settings, usually the router or the ISP DNS. The record type is chosen with -type=, a name server can be given as the last argument.

nslookup example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
nslookup -type=TXT _dmarc.example.com
nslookup -type=A example.com 8.8.8.8

The line "Non-authoritative answer" is not an error: it only means a resolver answered from its cache rather than the zone's name server. For the current state after a change, ask the authoritative name server directly by giving it as the last argument: nslookup -type=TXT example.com ns1.host.com.

dig on Linux and macOS

dig is more verbose and better for scripts. macOS ships it, on Debian and Ubuntu it lives in the dnsutils package, on Fedora in bind-utils. The record type goes after the domain, a name server with a leading @. +short reduces the output to the values.

dig example.com A +short
dig example.com MX
dig example.com TXT +short
dig example.com NS +short
dig _dmarc.example.com TXT +short
dig selector1._domainkey.example.com TXT +short
dig @ns1.host.com example.com A
dig example.com ANY +noall +answer

The header of the full output holds two useful details: the flags field, where aa marks an authoritative answer, and the TTL in the second column of every answer line. A cached answer counts the TTL down; the authoritative server shows the full value from the zone. Many servers no longer answer ANY completely, so query the types individually for a full picture.

Resolve-DnsName in PowerShell

PowerShell offers Resolve-DnsName, a cmdlet that returns objects instead of text and can therefore be sorted, filtered and used in scripts. The name server is given with -Server, -DnsOnly bypasses the hosts file and the machine's cache.

Resolve-DnsName example.com
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type TXT | Select-Object -ExpandProperty Strings
Resolve-DnsName _dmarc.example.com -Type TXT
Resolve-DnsName example.com -Type A -Server 1.1.1.1 -DnsOnly
Resolve-DnsName example.com -Type NS | ForEach-Object { Resolve-DnsName example.com -Type A -Server $_.NameHost }

The last line is the trick for migrations: it finds the name servers of the zone and asks each of them for the A record. If all return the same value, the zone is consistent and differences between users are only a matter of TTL.

Authoritative or cached: the difference

All three tools ask your machine's resolver by default, and it answers from its cache as long as the TTL has not expired. After a DNS change you therefore often still see the old value although the host saved it long ago. The way to the truth is always the same:

  1. Find the name servers of the zone: dig example.com NS +short or nslookup -type=NS example.com.
  2. Ask one of them directly: dig @ns1.host.com example.com TXT or nslookup -type=TXT example.com ns1.host.com.
  3. If the new value is there, the change is correct. Every resolver catches up once its old copy has expired.
  4. For control ask a public resolver (8.8.8.8, 1.1.1.1) and flush the local cache: ipconfig /flushdns on Windows, sudo resolvectl flush-caches on Linux, sudo dscacheutil -flushcache on macOS.

Common tasks with client domains

The commands used most often in agency work:

  • Verify a hosting move: dig example.com NS +short shows whether the new name servers are already on file at the registry.
  • Read SPF: dig example.com TXT +short | grep spf1 filters the SPF record out of all TXT records.
  • Check a DKIM key: dig selector1._domainkey.example.com TXT +short; with Microsoft 365 a CNAME to onmicrosoft.com appears.
  • Find mail servers: dig example.com MX +short, then resolve the hosts with dig mail.example.com A +short.
  • Reverse DNS of a mail server IP: dig -x 203.0.113.10 +short or nslookup 203.0.113.10.
  • Certificate authorities: dig example.com CAA +short shows who may issue certificates.

When a tool is the better choice

The command line shows one moment on one machine. The DNS checker always queries authoritatively, explains every record and flags errors such as a CNAME next to other records or missing CAA entries. And for the question whether something changes tomorrow you need monitoring anyway, which queries the zone regularly and reports differences.

Frequently asked questions

nslookup says "Non-authoritative answer", what does that mean?
The answer came from a resolver cache, not from the zone's name server. That is normal and not an error. For the current state, name the authoritative name server directly.
Why does dig show a different value than my browser?
Browser and operating system have their own caches, plus the resolver. After a change the values only agree once all TTLs have expired. Flush the cache and ask the authoritative server.
Can I see all records of a domain with dig?
Not reliably. Many servers answer ANY only partially, and hosts do not allow zone transfers (AXFR). Query the types individually or use the DNS checker, which shows the common types together.
Check now

Free DNS lookup straight from the authoritative name server: A, AAAA, CNAME, MX, TXT, NS and CAA records at a glance. No sign-up, every record explained.

DomainWarn checks SPF, DKIM, DMARC, DNS and certificates of all client domains regularly and reports changes before mail lands in spam.

Monitor this domain continuously14-day free trial, no credit card.

More guides