DNS Lookup Tool — Complete Guide

DNS is a globally distributed, hierarchical database. When your computer needs to resolve api.github.com, it goes through a multi-step process called recursive resolution:

The DNS Resolution Chain

1. Local cache check — Your OS checks its local DNS cache first. On Linux, run resolvectl statistics; on Windows, ipconfig /displaydns.
2. Recursive resolver — If not cached, the query goes to your configured resolver (e.g., 8.8.8.8 for Google, 1.1.1.1 for Cloudflare).
3. Root nameservers — The resolver asks one of 13 root nameserver clusters (a.root-servers.net through m.root-servers.net) which TLD nameserver handles .com.
4. TLD nameservers — The .com TLD nameserver returns the authoritative nameservers for github.com.
5. Authoritative nameserver — The authoritative nameserver returns the actual record (e.g., the A record for api.github.com).

# Trace the full resolution path with dig
dig +trace api.github.com A

# Example output excerpt:
# .                       82893   IN  NS  a.root-servers.net.
# com.                    172800  IN  NS  a.gtld-servers.net.
# github.com.             172800  IN  NS  ns1.p16.dynect.net.
# api.github.com.         60      IN  A   140.82.112.6

DNS Query Types

• Recursive query — Sent by your client to the resolver. "Give me the final answer."
• Iterative query — Used between resolvers and authoritative servers. "Give me the best answer you have or a referral."
• Non-recursive query — The resolver already has the answer cached.

# Query with specific nameserver (bypass local resolver)
dig @8.8.8.8 github.com A

# Check what nameserver your system uses
cat /etc/resolv.conf    # Linux/macOS
# nameserver 192.168.1.1

# Windows equivalent
ipconfig /all | findstr "DNS Servers"

DNS records are the individual entries stored in a zone file. Each type has a specific purpose. Knowing them prevents hours of misconfiguration debugging.

Real Record Examples from Zone Files

; A records
example.com.        3600  IN  A      93.184.216.34
www.example.com.    3600  IN  A      93.184.216.34

; AAAA record
example.com.        3600  IN  AAAA   2606:2800:220:1:248:1893:25c8:1946

; CNAME — note: trailing dot is mandatory in zone files
blog.example.com.   3600  IN  CNAME  myapp.vercel.app.

; MX records with priorities
example.com.        3600  IN  MX     1  aspmx.l.google.com.
example.com.        3600  IN  MX     5  alt1.aspmx.l.google.com.
example.com.        3600  IN  MX     10 alt2.aspmx.l.google.com.

; TXT — SPF record
example.com.        3600  IN  TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

; TXT — DMARC record
_dmarc.example.com. 3600  IN  TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; NS records
example.com.        86400 IN  NS     ns1.cloudflare.com.
example.com.        86400 IN  NS     ns2.cloudflare.com.

; SOA record
example.com.        3600  IN  SOA    ns1.cloudflare.com. dns.cloudflare.com. (
                                     2026031901  ; serial
                                     10800       ; refresh (3 hours)
                                     3600        ; retry (1 hour)
                                     604800      ; expire (7 days)
                                     3600 )      ; minimum TTL

A raw DNS response contains more information than most tools surface by default. Here's how to interpret every field.

Anatomy of a dig Response

$ dig github.com A

; <<>> DiG 9.18.0 <<>> github.com A
;; global options: +cmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;github.com.                    IN      A

;; ANSWER SECTION:
github.com.             60      IN      A       140.82.114.4

;; Query time: 8 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Mar 19 10:00:00 UTC 2026
;; MSG SIZE  rcvd: 55

Field-by-Field Breakdown

DNS Response Codes (RCODEs)

Understanding TTL Strategy

# Low TTL = faster propagation but more DNS queries (cost + latency)
# Typical values:
#   60     — Active change in progress (lower before migrations)
#   300    — Dynamic or frequently-changed records
#   3600   — Standard web records
#   86400  — Stable NS, MX records
#   604800 — SOA expire (7 days)

# Check TTL and watch it count down:
watch -n 10 "dig +nocmd +noall +answer github.com A"

When you change a DNS record, the new value doesn't instantly appear everywhere. Each resolver around the world has cached the old value and will keep serving it until that cache expires — this is DNS propagation, and it can take anywhere from minutes to 48 hours.

The Propagation Math

Old TTL on your A record: 3600 seconds (1 hour)

Time zero: You change 203.0.113.10 → 198.51.100.20 at your registrar.

T+0    — Authoritative nameserver has new record (immediate).
T+0    — Resolvers that query NOW get the new value.
T+60m  — All resolvers that queried in the last hour expire their cache.
T+60m  — Effective propagation complete (for TTL=3600).

With TTL=86400 (24h default), worst case is 24–48h.

How to Pre-Reduce Propagation Time

Lower TTL 24–48 hours before making changes:

# Step 1: 48h before migration, lower TTL to 300s (5 min)
# (Do this in your DNS provider's dashboard)

# Step 2: Verify the low TTL has propagated
dig +nocmd +noall +answer example.com A
# example.com.    300   IN  A  203.0.113.10

# Step 3: Make your DNS change
# Step 4: Wait 5 minutes
# Step 5: After confirmed working, raise TTL back to 3600+

Checking Propagation Across Global Resolvers

# Query multiple public resolvers manually:
for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222 64.6.64.6; do
  echo -n "$resolver: "
  dig @$resolver +short example.com A
done

# Output during propagation:
# 8.8.8.8: 203.0.113.10    (old - cached)
# 1.1.1.1: 198.51.100.20   (new - already updated)
# 9.9.9.9: 198.51.100.20   (new)
# 208.67.222.222: 203.0.113.10  (old - cached)
# 64.6.64.6: 198.51.100.20  (new)

Most DNS problems fall into a handful of categories. Here's a systematic diagnostic playbook.

Issue 1: NXDOMAIN — Domain Not Found

dig example-newsite.com A
# status: NXDOMAIN

# Diagnose:
# 1. Check domain registration
whois example-newsite.com | grep -E "Expir|Status|Name Server"

# 2. Check if nameservers are set
dig example-newsite.com NS
# If NXDOMAIN here too, domain isn't registered or NS not set.

# 3. Verify with registrar's authoritative server directly
dig @a.iana-servers.net example-newsite.com A

Issue 2: SERVFAIL — Server Failure

dig example.com A
# status: SERVFAIL

# Common causes:
# - DNSSEC validation failure (most common in 2026)
# - Nameserver misconfiguration
# - Zone file syntax error

# Test without DNSSEC validation:
dig +cd example.com A  # +cd = checking disabled
# If this succeeds, DNSSEC is broken.

# Check DNSSEC chain:
dig +dnssec example.com A
dig example.com DNSKEY
dig example.com DS

Issue 3: Wrong IP / Cached Old Record

# Flush local DNS cache:
# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Windows
ipconfig /flushdns

# Then verify:
dig +short example.com A  # Should show new IP

Issue 4: Email Delivery Problems (MX/SPF/DKIM)

# Check MX records
dig example.com MX
# 10 aspmx.l.google.com.

# Verify SPF record
dig example.com TXT | grep "spf"
# "v=spf1 include:_spf.google.com ~all"

# Verify DKIM (selector depends on your email provider)
dig google._domainkey.example.com TXT
# "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

# Verify DMARC
dig _dmarc.example.com TXT
# "v=DMARC1; p=reject; rua=mailto:reports@example.com"

Issue 5: CNAME Chain / Loop

# CNAME chains slow resolution. Maximum recommended depth: 3
dig +trace www.example.com CNAME

# Detect loops — this will hang or timeout:
# A CNAME → B CNAME → A  (loop!)

# Fix: resolve CNAME chain manually and check for circularity
dig +short www.example.com CNAME  # Get first target
dig +short [target] CNAME         # Follow chain

DNS was designed in the 1980s without security in mind. Modern DNS security layers address three attack vectors: cache poisoning, man-in-the-middle interception, and DNS hijacking.

DNSSEC — Cryptographic Integrity

DNSSEC adds digital signatures to DNS records. Resolvers can verify that records haven't been tampered with in transit.

# Check if a domain has DNSSEC enabled
dig +dnssec example.com A
# Look for RRSIG record in the additional section
# RRSIG  A 13 2 3600 20260419000000 20260319000000 34505 example.com. [signature]

# Check DS record at parent zone (proves chain of trust)
dig example.com DS

# Verify DNSSEC chain with online tools:
# https://dnsviz.net/d/example.com/dnssec/

# Check DNSKEY (zone signing key)
dig example.com DNSKEY
# 257 3 13 [key-data]  ← KSK (Key Signing Key)
# 256 3 13 [key-data]  ← ZSK (Zone Signing Key)

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Traditional DNS queries travel in plaintext on UDP port 53. DoH encrypts queries inside HTTPS; DoT uses TLS on port 853.

# Query Cloudflare's DoH endpoint directly with curl
curl -s "https://cloudflare-dns.com/dns-query?name=github.com&type=A"   -H "accept: application/dns-json" | jq '.Answer[]'

# Output:
# {
#   "name": "github.com.",
#   "type": 1,
#   "TTL": 60,
#   "data": "140.82.114.4"
# }

# Configure systemd-resolved to use DoT (Linux)
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes

DNS Hijacking Attack Vectors

A DNS lookup tool isn't just for troubleshooting — it's a core part of deployment verification, security auditing and infrastructure planning.

Developer Deployment Checklist

# Before deploying a new domain/subdomain:
# 1. Verify A record points to correct server
dig +short api.myapp.com A
# Expected: 198.51.100.42

# 2. Confirm TLS cert can be issued (check CAA)
dig myapp.com CAA
# 0 issue "letsencrypt.org"  ← Only Let's Encrypt can issue certs

# 3. Verify CDN CNAME is set correctly
dig +short static.myapp.com CNAME
# myapp.azureedge.net.

# 4. Check email infrastructure
dig myapp.com MX
dig myapp.com TXT  # SPF, DKIM, DMARC

# 5. Confirm HTTPS redirects work (check both A and AAAA for dual-stack)
dig +short myapp.com AAAA

Sysadmin Use Cases

• Post-migration validation — Confirm all records updated after server move
• Reverse DNS for email reputation — dig -x 198.51.100.42 confirms PTR record matches your mail server hostname
• Monitoring nameserver health — Query each NS directly to ensure all are returning consistent answers
• Subdomain enumeration (authorized) — Use DNS zone transfer attempts or tooling like subfinder during security audits
• Cloud infrastructure verification — Confirm AWS Route53/Cloudflare records match Terraform-defined state

# Check all 4 nameservers return the same answer (consistency check)
for ns in ns1.cloudflare.com ns2.cloudflare.com ns3.cloudflare.com ns4.cloudflare.com; do
  echo -n "$ns: "
  dig @$ns +short example.com A
done

# Reverse DNS lookup
dig -x 140.82.114.4 +short
# lb-140-82-114-4-fra.github.com.

# Zone transfer attempt (legitimate on your own zones)
dig @ns1.example.com example.com AXFR

# SOA serial check across nameservers (should match)
for ns in ns1 ns2; do
  dig @$ns.example.com example.com SOA +short | awk '{print "$ns:", $3}'
done

Automation and CI/CD Integration

#!/bin/bash
# DNS health check script for CI/CD pipeline

DOMAIN="api.myapp.com"
EXPECTED_IP="198.51.100.42"
ACTUAL_IP=$(dig +short $DOMAIN A | head -1)

if [ "$ACTUAL_IP" = "$EXPECTED_IP" ]; then
  echo "✓ DNS OK: $DOMAIN → $ACTUAL_IP"
  exit 0
else
  echo "✗ DNS MISMATCH: expected $EXPECTED_IP, got $ACTUAL_IP"
  exit 1
fi