Dig and Nslookup Commands in 2026 – Complete Guide

DNS problems can affect websites, email, and APIs when records point to the wrong place. Dig and Nslookup provide practical ways to inspect those records quickly.

This guide explains how both commands work, where to install them, and how to use common DNS queries for faster troubleshooting without relying on graphical tools.

You will learn useful commands, compare Dig with Nslookup and Host, trace DNS resolution, troubleshoot common errors, automate checks, and follow reliable DNS practices with confidence.

Why Dig and Nslookup Commands Matter?

Every website, mail server, and API depends on DNS resolving correctly. When a domain does not resolve, or resolves to the wrong IP address, the result is downtime, bounced email, or broken SSL.

DNS lookup tools like dig and nslookup let administrators verify, in seconds, whether a DNS record is published correctly, which name server is authoritative, and how far a change has propagated across the internet.

Both tools are free, pre-installed or easily installable on every major operating system, and require no GUI, making them the first step in any DNS troubleshooting workflow before escalating to a hosting provider or registrar.

What Is the Dig Command?

Dig (Domain Information Groper) is a command line DNS lookup utility included in the dnsutils (Debian/Ubuntu) or bind-utils

(RHEL/CentOS/AlmaLinux) packages. It queries DNS servers directly and returns a raw, detailed response including the question asked, the

answer section, the authority section, timing, and the server that answered.

Why sysadmins prefer dig:

• Consistent, parseable output that works well in bash scripts
• Full DNSSEC and DNS trace support (+trace)
• Batch lookups from a file with -f
• Query timing and TTL shown by default

What Is the Nslookup Command?

Nslookup (Name Server Lookup) is a DNS query tool available by default on Windows, macOS, and Linux.

It supports both a quick non-interactive mode for single lookups and an interactive mode for running several queries inside one session.

For every nslookup flag, record type option, and troubleshooting example in depth, see our dedicated nslookup command guide.

Nslookup remains the default DNS tool on Windows Command Prompt and PowerShell, which is why it is still widely taught even though most Linux distributions now favor dig.

How to Install Dig and Nslookup

Nslookup is pre-installed on Windows, macOS, and most Linux distributions. Dig usually needs to be installed separately on fresh Linux servers.

Install Dig on Debian / Ubuntu

sudo apt update
sudo apt install dnsutils -y

Install Dig on RHEL / CentOS / AlmaLinux

sudo yum install bind-utils -y

Verify Installation

dig -v
nslookup -version

Dig Command Syntax

The basic syntax format:

dig [@DNS-server] [domain] [record-type] [options]

Example:

dig youstable.com @8.8.8.8

If no DNS server or record type is specified, dig queries the system’s default resolver for the A record.

Most Used Dig Commands and Practical Examples

A Record Lookup (Domain to IP)

dig example.com A

MX Record Lookup (Mail Server Check)

dig example.com MX

NS Record Lookup (Authoritative Name Servers)

dig example.com NS

TXT Record Lookup (SPF, DKIM, Verification)

dig example.com TXT

SOA Record Lookup (Primary DNS Authority)

dig example.com SOA

CNAME Lookup (Alias Records)

dig www.example.com CNAME

Reverse DNS Lookup (PTR Record)

Get hostname from IP:

dig -x 93.184.216.34

Short Answer Only Output

dig example.com +short

Answer Section Only (No Header/Footer Noise)

dig example.com +noall +answer

Full DNS Resolution Path (Trace)

dig example.com +trace

Batch Lookup From a File

dig -f domains.txt

Nslookup Command Quick Reference

The equivalent nslookup command syntax for the same DNS checks:

Dig vs Nslookup vs Host: Full Comparison

In short: use dig for detailed, scriptable, DNSSEC-aware diagnostics on Linux and macOS; use nslookup for quick checks on Windows or when dig is unavailable; use host for the fastest one-line answer.

Real-World DNS Troubleshooting Scenarios

Common DNS Error Messages and Fixes

Understanding Dig +trace Output

The +trace flag makes dig follow the entire DNS delegation chain, from the root servers down to the authoritative name server, instead of relying on a resolver’s cached answer:

dig example.com +trace

.                       518400  IN  NS  a.root-servers.net.
com.                    172800  IN  NS  a.gtld-servers.net.
example.com.            172800  IN  NS  ns1.example.com.
example.com.            300     IN  A   93.184.216.34

This is the fastest way to confirm exactly which name server is authoritative for a domain, and to catch broken delegation after a domain transfer or nameserver change.

Automating DNS Checks With Dig in Shell Scripts

Because dig’s +short output is clean and script friendly, it is commonly used in bash monitoring scripts and cron jobs to detect DNS or propagation failures:

#!/bin/bash
DOMAIN="example.com"
EXPECTED_IP="93.184.216.34"
CURRENT_IP=$(dig +short "$DOMAIN" A)

if [ "$CURRENT_IP" != "$EXPECTED_IP" ]; then
  echo "DNS mismatch for $DOMAIN: expected $EXPECTED_IP, got $CURRENT_IP"
fi

This pattern is useful for alerting when a domain’s A record changes unexpectedly, such as during a hijack attempt or an accidental DNS edit.

Best Practices for Using Dig and Nslookup

Use dig and nslookup carefully to get accurate DNS results and avoid confusing cached or incomplete responses. Follow these practices when troubleshooting DNS issues:

• Check multiple DNS resolvers: Query public resolvers such as 1.1.1.1 and 8.8.8.8 to compare results and identify possible propagation differences.
• Use dig +trace for delegation issues: When a domain gives inconsistent results, use dig example.com +trace to follow the DNS resolution path from the root servers to the authoritative name server.
• Use clean output for scripts: Use dig +short or dig +noall +answer when automating DNS checks. These options make the output easier to parse in shell scripts.
• Check the SOA record and TTL: Review the SOA record and its TTL before assuming that a DNS change has fully propagated across different resolvers.
• Query authoritative servers directly: Use dig example.com @ns1.example.com to check the authoritative response and separate DNS configuration problems from resolver caching.
• Verify the correct record type: Make sure you query the record relevant to the problem, such as A for website IP addresses, MX for email routing, or TXT for SPF, DKIM, and verification records.

These practices make DNS troubleshooting more reliable and help identify whether an issue comes from the DNS configuration, authoritative server, resolver cache, or propagation.

FAQs