dig Command Builder

Build a dig command without memorising its syntax quirks. Enter a domain or IP, pick the record type, optionally specify an @resolver, and toggle options like +short for terse output, +trace for full delegation chain, +dnssec for RRSIG records, and -x for reverse PTR lookups. The command assembles in real time.

How to use the dig Command Builder

Enter the domain name (e.g. example.com) or an IP address if you are doing a reverse lookup. Select the record type: A for IPv4 addresses, AAAA for IPv6, MX for mail servers, TXT for SPF/DKIM/verification records, CNAME for aliases, NS for nameservers, SOA for zone authority, CAA for certificate authority authorisation, PTR for reverse DNS, or ANY for all available records.

The @Resolver field sets which DNS server handles the query. Use 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) to bypass your local resolver and query authoritative results. This is useful for checking propagation from an external vantage point.

+short strips the verbose answer section and prints just the records — perfect for scripts. +trace forces dig to follow the full delegation chain from the root servers, showing exactly which nameserver answered at each step. +dnssec requests DNSSEC signature records (RRSIG) so you can verify a zone is signed. -x switches to reverse lookup mode: dig automatically converts the IP to its reverse-DNS form (e.g. 1.0.168.192.in-addr.arpa) and queries for a PTR record.

About dig

dig (Domain Information Groper) is the standard command-line DNS query tool, available on macOS, Linux and via WSL on Windows. Unlike nslookup or host, dig outputs the full DNS response in a structured, scriptable format including status (NOERROR, NXDOMAIN, SERVFAIL), flags (QR, AA, TC, RD, RA), the question section, answer section, authority section and additional records. This makes it the preferred tool for debugging DNS issues.

The syntax is non-obvious: the resolver comes before the name (dig @8.8.8.8 example.com), query options are prefixed with + (+short, +trace), and BIND-style options use a single hyphen (-x for reverse, -p for port). Reverse lookups require -x plus an IP address — dig handles the conversion to the .in-addr.arpa or .ip6.arpa form internally.

Common debugging scenarios: use +trace to determine whether a DNS change has propagated to root servers yet; use @1.1.1.1 to verify the authoritative record independently of your ISP resolver's cache; use +short to extract just the IP in a shell script; use +dnssec to verify that a zone is DNSSEC-signed and check RRSIG validity. For DNSSEC chain validation, combine with +sigchase if your dig version supports it.

Common use cases

  • DNS propagation checking — query @8.8.8.8 and @1.1.1.1 to see if a record change has propagated beyond your local resolver.
  • MX record verification — confirm mail server records are correct before switching email providers or configuring SPF/DKIM.
  • DNSSEC validation — use +dnssec to confirm a zone is signed and retrieve RRSIG records for debugging validation failures.
  • Reverse DNS lookup — check that an IP has correct PTR records (required for mail deliverability and some firewall rules).
  • Full delegation trace — use +trace to follow the resolution path from root servers, useful for diagnosing lame delegations or glue record issues.
  • Scripted DNS checks — use +short to extract just the record value in a CI pipeline health check or monitoring script.

Frequently asked questions

What is the difference between dig and nslookup?
dig outputs the full DNS wire-protocol response in a structured, machine-readable format with status codes and flags. nslookup is simpler and more interactive but inconsistent across platforms. dig is preferred for debugging and scripting; nslookup is fine for quick lookups on Windows where dig may not be installed.

Why does +trace show different results than a regular query?
+trace bypasses your local resolver's cache and follows the delegation chain from the root servers (.) down to the authoritative nameserver for the zone. This shows the real TTL and current state of the record, not what your resolver has cached.

How do I check if DNSSEC is working?
Add +dnssec to request RRSIG records in the answer. If the zone is signed, you'll see RRSIG lines alongside each record. For full chain validation use dig +sigchase (if supported) or an online DNSSEC validator like dnsviz.net.

What does NXDOMAIN mean?
NXDOMAIN (Non-Existent Domain) means the queried name does not exist in the DNS. It is returned by the authoritative server, not just a caching miss. A SERVFAIL status means the server was unable to complete the query (often a DNSSEC validation failure or misconfigured zone).

Can I query a specific DNS port?
Yes: dig @server -p 5353 name type. Port 5353 is used by mDNS (Multicast DNS / Bonjour). Custom ports are useful for testing local DNS servers or alternative resolvers.