Updated: 11 October 2026. If a domain points to the wrong IP, email stops arriving or a DNS change seems to take forever, the dig command is one of the quickest ways to see what a DNS resolver actually returns. Unlike a browser error, dig exposes record values, authoritative nameservers, response codes and time-to-live (TTL) information.
This hands-on guide shows how to perform a DNS lookup with dig on Linux and macOS, inspect common record types and troubleshoot a website or server migration. All commands use example.com and documentation IP addresses as safe examples; substitute a domain you administer.
What is dig?
dig stands for Domain Information Groper. It is a command-line tool included with BIND utilities that sends DNS queries and prints replies. Network operators use it to inspect IPv4 and IPv6 addresses, mail routing, TXT verification, delegation and reverse DNS. It is diagnostic: running dig does not create or change DNS records.
How to install dig on Ubuntu, Debian, Linux and macOS
First check whether it is available:
dig -vOn Ubuntu or Debian, the appropriate package is generally dnsutils or bind9-dnsutils depending on the distribution release:
sudo apt update
sudo apt install dnsutilsOn Fedora, RHEL and compatible systems, the package is commonly bind-utils:
sudo dnf install bind-utilsOn macOS, dig is generally available from the system command line. If your environment lacks it, install the BIND utilities through a supported package manager. On Windows, use an environment such as WSL or an appropriate BIND tools installation.
Basic dig command syntax
dig [@DNS_SERVER] DOMAIN RECORD_TYPE [OPTIONS]For example, this requests the A record for a domain:
dig example.com ATypical results contain a HEADER with status, a QUESTION SECTION, and (when present) an ANSWER SECTION. The answer lists the owner name, TTL, class, record type and returned data. The NOERROR status means the DNS query was processed successfully; it does not guarantee that the requested record exists.
Use +short to show a concise result:
dig example.com A +short12 useful dig commands for DNS administrators
1. Look up an IPv4 address (A record)
dig example.com A +shortAn A record maps a DNS name to an IPv4 address. Query the exact hostname used for your site or API.
2. Look up an IPv6 address (AAAA record)
dig example.com AAAA +shortAAAA records map names to IPv6 addresses. If a hostname has an obsolete AAAA record, IPv6-capable clients may connect to a different server than IPv4 clients.
3. Find mail exchanger records (MX)
dig example.com MX +shortMX responses include preference values and mail hosts. Lower preference numbers indicate higher priority. Check both MX and the returned mail host addresses if inbound email fails.
4. Check authoritative nameserver delegation (NS)
dig example.com NS +shortCompare the delegated nameservers with those configured at the registrar. During migration, make sure you edit the DNS zone served by the active authoritative nameservers—not an unused copy.
5. Inspect TXT records including SPF and verification
dig example.com TXT +shortTXT records may contain email policy, domain ownership tokens and other metadata. DKIM values typically live at a selector-specific hostname, for example:
dig selector1._domainkey.example.com TXT +shortReplace selector1 with the actual DKIM selector. TXT strings may be split into quoted chunks in the display.
6. Check alias records (CNAME)
dig www.example.com CNAME +shortA CNAME points a name at another hostname, not directly to an IP. The presence of a CNAME does not mean that every name in the chain is configured correctly; check the target too.
7. Read the start-of-authority record (SOA)
dig example.com SOAThe SOA contains zone metadata such as the primary nameserver, administrative mailbox representation and serial. It can help distinguish old and new DNS zone copies.
8. Perform a reverse DNS lookup (PTR)
dig -x 192.0.2.25 +shortReverse DNS is managed through the corresponding reverse DNS zone, commonly by the IP address provider. An A record does not automatically create a PTR record. The address above is a documentation-only example.
9. Query a specific public resolver
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com AComparing two resolvers can reveal caching differences. This does not prove what every visitor worldwide will see.
10. Query an authoritative nameserver directly
dig @ns1.example.net example.com A +norecurseReplace ns1.example.net with a real authoritative nameserver from the domain’s delegation. Direct authoritative answers are helpful for separating incorrect zone configuration from resolver caching.
11. Trace DNS delegation from the root
dig example.com A +traceThe +trace option walks the delegation hierarchy and exposes referrals from root servers onward. It is useful for investigating incorrect nameserver delegation. It does not, by itself, prove that DNSSEC signatures are valid.
12. Request DNSSEC-related data
dig example.com DNSKEY
dig example.com A +dnssec+dnssec requests DNSSEC records where available; it does not independently validate trust. Use an actual validating resolver or a DNSSEC validation tool when investigating signature problems.
How to read dig output
| Field | Meaning | When it helps |
|---|---|---|
| Status: NOERROR | The requested DNS transaction succeeded | Differentiate successful empty answers from errors |
| NXDOMAIN | The queried name does not exist according to the answer | Detect misspellings or missing DNS names |
| ANSWER SECTION | Returned resource records, if any | Inspect addresses, MX targets and TTLs |
| SERVER | Resolver that answered | Compare resolver behavior |
| TTL | Remaining cache lifetime in seconds for the returned RR | Understand cached old values |
| AUTHORITY SECTION | Relevant authority/delegation data | Investigate nameserver and negative responses |
A NOERROR response without an A record may simply mean the name exists but has no A record (NODATA). An empty +short response is not enough to determine why: repeat without +short and inspect the status and authority section.
Troubleshooting DNS after moving a website to a VPS
- Confirm the intended address. Check the correct IPv4/IPv6 address on your new server before touching the DNS zone.
- Confirm delegation. Use
dig example.com NSand compare it with the registrar settings. - Inspect the authoritative answer. Query the active nameserver directly to find out what the zone currently publishes.
- Compare recursive caches. Ask two resolvers using
@1.1.1.1and@8.8.8.8, noting their reported TTLs. - Check both A and AAAA. An outdated IPv6 record can cause intermittent-looking failures even if IPv4 is correct.
- Check the web server separately. Correct DNS does not guarantee that HTTP, HTTPS, TLS certificates, firewalls or application configuration are working.
For a managed migration, work through the domain, web server and certificate changes as separate steps. For related reading, see Dotzo’s article on hosting and SEO and the available Dotzo hosting options.
For teams deploying applications with AI coding assistants, our Claude AI for developers guide covers staging, review and safer change-control practices.
Example dig results: NXDOMAIN, NOERROR with no records, and SERVFAIL
Important: The following short transcripts are illustrative examples, not measurements from a live domain. They show how to interpret the status field. Use your own domain and resolver to obtain actual values.
NXDOMAIN: the queried DNS name does not exist
$ dig missing.example.com A +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1What to check: spelling, whether the subdomain was created in the active zone, and whether you are querying the expected public or private DNS view. An NXDOMAIN response does not necessarily mean your entire domain is expired.
NOERROR with an empty answer: the name may lack the requested record
$ dig example.com AAAA +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12346
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1What to check: ask for A or CNAME as appropriate and inspect the full reply. An empty AAAA answer can be normal when the hostname has no IPv6 record. The example is illustrative; example.com may return different real records.
SERVFAIL: the resolver could not complete the answer
$ dig example.com A +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12347
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0What to check: compare dig @1.1.1.1 example.com A against dig @8.8.8.8 example.com A, inspect authoritative server availability and test DNSSEC validation where applicable. SERVFAIL is not proof of one specific cause; it can arise from connectivity, authoritative problems or DNSSEC.
Quick troubleshooting decision table
| Observed result | Likely next check | Useful command |
|---|---|---|
| NXDOMAIN | Hostname spelling and delegated zone | dig example.com NS |
| NOERROR, empty answer | Check the right record type and name | dig example.com A |
| SERVFAIL | Authoritative health and DNSSEC | dig example.com A +trace |
| Old IP from some resolvers | Cached TTL or split configuration | dig @1.1.1.1 example.com A |
| Correct DNS, website down | TLS, web server, firewall, virtual host | curl -I https://example.com |
For a proper DNSSEC validation test, BIND supplies delv in addition to dig; the official ISC BIND documentation explains why dig +dnssec alone does not validate a DNSSEC chain. If your website’s DNS points to a new Dotzo VPS, confirm the virtual host and certificate independently of the DNS response.
Common dig mistakes to avoid
- Assuming dig ANY means all records. Modern DNS servers may limit or decline ANY replies, so request individual record types instead.
- Mixing root and www records.
example.comandwww.example.comare distinct DNS names. - Assuming “propagation” is a fixed 24-hour timer. Cache lifetime, delegation changes and negative caching vary.
- Editing the wrong DNS host. The authoritative nameservers, not the server that hosts the website, determine which DNS zone responds.
- Confusing DNS with connectivity. A correct record does not mean port 443 is reachable or the TLS certificate is valid.
dig DNS lookup FAQ
What does dig stand for?
Domain Information Groper. It queries DNS nameservers and displays their responses.
How do I find a domain’s IP address with dig?
Run dig example.com A +short for IPv4 or dig example.com AAAA +short for IPv6, replacing the example domain with yours.
How do I check DNS propagation with dig?
Compare the authoritative answer and responses from multiple recursive resolvers. Differences often indicate caches or differing delegation paths, not necessarily an error with the new server.
Can dig change DNS records?
No. It is a query and troubleshooting utility. DNS changes must be made through the appropriate DNS provider or nameserver administration interface.
Is dig available on Windows?
You can use dig in a suitable Windows environment such as WSL or installed BIND DNS tools. Windows also includes DNS querying alternatives, but their output and flags differ.
Summary
Use dig to prove what DNS says before blaming web hosting, email or your application. Start with A/AAAA, NS and MX; then use @resolver, +trace, direct authoritative queries and TTL checks for deeper diagnosis. If you’re hosting a site on a Dotzo VPS or dedicated server, these checks help isolate DNS configuration from server-level faults.
Technical reference: ISC BIND 9 dig manual. Commands shown are illustrative; DNS output depends on the records that exist when you query.
