Skip to main content

DNS Utilities

DNS utilities are command-line tools used to query, troubleshoot, and validate DNS resolution. They help confirm that domain names resolve to the expected IP addresses, that authoritative name servers respond correctly, and that DNS records (A/AAAA/CNAME/MX/TXT/NS/SOA) are published and propagated as intended. On VPS and WordPress environments, DNS utilities are used daily for domain onboarding, SSL issuance debugging, CDN verification, email record validation, and incident triage when a site is unreachable.

Background and history​

The Domain Name System (DNS) predates modern web hosting and has long been a foundational dependency for internet services. Early Unix systems relied on tools like nslookup and host to query DNS. Later, dig became the standard diagnostic tool due to its detailed output and scriptability. Linux distributions package these tools in convenience bundles (commonly named dnsutils, bind-utils, or similar), making it easy to install a consistent set of DNS troubleshooting commands.

Adoption and where it’s commonly used​

DNS utilities are commonly used in:

  • VPS provisioning and domain setup (A/AAAA/CNAME validation)
  • WordPress migrations and DNS cutovers (TTL and propagation checks)
  • SSL/TLS troubleshooting (ACME challenges, CAA records, TXT records)
  • CDN and reverse proxy validation (CNAME chains, proxy targets)
  • Email DNS validation (MX, SPF, DKIM, DMARC)

Maintained by

  • Maintained by the BIND project community and Linux distribution communities (tooling and packaging varies by distro).

Best when to use​

  • You need to verify record correctness and propagation.
  • You need to diagnose “domain not resolving” or “wrong server” issues.
  • You need to confirm authoritative vs recursive answers.
  • You need to validate email DNS records (SPF/DKIM/DMARC) and CAA.

Not suitable when​

  • You need full DNS server management and zone editing (use your DNS provider’s management tools).
  • You need long-term DNS monitoring with alerting (use external monitoring or a metrics stack).
  • You need packet-level DNS debugging (use tcpdump/Wireshark).

Compatibility notes​

  • Package names differ:

    • Debian/Ubuntu: dnsutils
    • RHEL/Fedora/Rocky/AlmaLinux: bind-utils
    • Alpine: bind-tools

  • Some systems include systemd-resolved, which can affect local resolver behavior and caching.

  • Results may differ depending on whether you query:

    • the system resolver,
    • a specific recursive resolver (public DNS),
    • the authoritative nameserver.

Tools included and what they do​

ToolPurposeWhen to use
-
digDetailed DNS queries, records, flagsPrimary troubleshooting tool
hostQuick lookups with concise outputFast verification and scripts
nslookupLegacy lookup toolCompatibility checks; not preferred for deep debugging
Recommended default

Use dig for most DNS troubleshooting. Use host for fast confirmation when you do not need full DNS flags and section details.

Installation​

Debian/Ubuntu​

sudo apt update
sudo apt install -y dnsutils

RHEL/Fedora/Rocky/AlmaLinux​

sudo dnf install -y bind-utils

Alpine​

sudo apk add bind-tools

Verify tools are available:

command -v dig host nslookup

Concepts and how DNS lookups work​

DNS answers can be returned by:

  • Recursive resolvers (your system resolver, ISP resolvers, public DNS)
  • Authoritative name servers (the source of truth for a zone)

Key record types:

  • A: IPv4 address
  • AAAA: IPv6 address
  • CNAME: alias to another name
  • MX: mail exchangers
  • TXT: text records (SPF/DKIM/DMARC, ACME challenges)
  • NS: authoritative name servers
  • SOA: zone metadata, serial, default TTL timings

Common commands and examples​

Basic resolution​

Query A record:

dig example.com A

Query AAAA record:

dig example.com AAAA

Short answer only:

dig +short example.com A
dig +short example.com AAAA

Query a specific resolver (bypass local DNS)​

Use a public resolver:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Compare against your system resolver:

dig example.com A

Identify authoritative nameservers​

dig example.com NS +short

Show authoritative zone info:

dig example.com SOA

Follow CNAME chains​

dig www.example.com CNAME
dig www.example.com A

Or show everything relevant:

dig www.example.com +noall +answer

Check propagation and consistency across resolvers​

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "Resolver: $r"
  dig +short @"$r" example.com A
done

Practical use cases for VPS and WordPress​

Use case: Domain points to the wrong server after migration​

  1. Check current A/AAAA:
dig +short example.com A
dig +short example.com AAAA
  1. Check authoritative NS and query them directly:
dig example.com NS +short
dig @ns1.your-dns-provider.net example.com A
dig @ns2.your-dns-provider.net example.com A
  1. Confirm TTL values and whether caching is expected:
dig example.com A

Look for TTL values in the answer section.

Use case: CDN not working (CNAME chain and proxy target)​

dig www.example.com CNAME
dig +trace www.example.com

Use case: SSL issuance fails (ACME / DNS-01 TXT record)​

Confirm _acme-challenge TXT exists and matches:

dig _acme-challenge.example.com TXT
dig +short _acme-challenge.example.com TXT

Use case: Email DNS validation (SPF/DKIM/DMARC)​

SPF (TXT at root):

dig example.com TXT

DMARC:

dig _dmarc.example.com TXT

DKIM (selector-based):

dig selector1._domainkey.example.com TXT
Email records can be long

Some resolvers display TXT values split across strings. Compare the full record content, not only the first fragment.

Troubleshooting​

Symptom: DNS resolves locally but not from other networks​

Likely causes:

  • Local resolver cache still has old answers
  • Split-horizon DNS (internal vs external answers)
  • DNS provider propagation delay or wrong NS delegation

Checks:

  • Query multiple resolvers:
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com A
dig +short @9.9.9.9 example.com A
  • Confirm delegation:
dig example.com NS

Symptom: NXDOMAIN​

Likely causes:

  • Record does not exist
  • Wrong zone or typo
  • Domain not delegated correctly

Check authoritative path:

dig +trace example.com

Symptom: SERVFAIL​

Likely causes:

  • Broken DNSSEC
  • Authoritative server not responding
  • Upstream resolver issue

Checks:

  • Query authoritative NS directly (after finding NS):
dig example.com NS +short
dig @<authoritative-ns> example.com A

Symptom: Unexpected IPv6 behavior​

If AAAA exists but your server is not configured for IPv6, clients may fail or behave inconsistently.

Checks:

dig +short example.com AAAA
curl -6 -I https://example.com 2>/dev/null || true

Mitigation:

  • Publish AAAA only if the service is correctly reachable on IPv6.

Security notes​

  • Avoid running DNS debugging commands from untrusted machines if you are handling sensitive TXT values (some verification records can be security-relevant).
  • Be careful when sharing full DNS outputs publicly; they can reveal infrastructure details (hostnames, providers, mail routes).
  • DNS changes are a common target for account takeover; use strong auth and 2FA on DNS provider accounts.

Quick reference​

Most used dig forms​

GoalCommand
---
Quick A recorddig +short example.com A
Quick AAAA recorddig +short example.com AAAA
Query specific resolverdig @1.1.1.1 example.com A
Get NS delegationdig example.com NS +short
Get SOAdig example.com SOA
Trace delegation pathdig +trace example.com
Check TXTdig example.com TXT
Check DMARCdig _dmarc.example.com TXT
Check ACME TXTdig _acme-challenge.example.com TXT

host shortcuts​

GoalCommand
----
Quick lookuphost example.com
Specific record typehost -t MX example.com
Specific resolverhost example.com 1.1.1.1