Back to blog

DNS troubleshooting: nslookup, dig, DoH

· 7 min read

In brief: DNS issues are among the most common and hardest-to-diagnose causes of outages - because "DNS works for me" doesn't mean it works for your customers. Here's an overview of practical tools and procedures.

In brief: DNS issues are among the most common and hardest-to-diagnose causes of outages - because "DNS works for me" doesn't mean it works for your customers. Here's an overview of practical tools and procedures.

Most common DNS problems

  • Domain registration expired - the whole DNS stops working.
  • Wrong A/AAAA record - forgotten to update after server migration.
  • Missing CNAME / MX - email doesn't work while web does.
  • TTL not set up for fast changes - caches of providers still serve old data.
  • DNSSEC error - validators reject unsigned or wrongly signed records.
  • Geo-DNS failure - resolver from a certain region gets wrong answer.

nslookup: the simplest command

Available on all OS without installation. Uses the system default DNS server, but you can explicitly specify it as the second argument.

$ nslookup epulz.io
Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:      epulz.io
Address:   87.197.115.180

# Explicitly use Cloudflare DNS
$ nslookup epulz.io 1.1.1.1

# Specific record type
$ nslookup -type=MX gmail.com 8.8.8.8
$ nslookup -type=TXT _dmarc.epulz.io 1.1.1.1

dig: detailed DNS query for Unix

dig (Domain Information Groper) is significantly more detailed and flexible. Part of the bind-utils or dnsutils package.

$ dig epulz.io

;; QUESTION SECTION:
;epulz.io.                      IN      A

;; ANSWER SECTION:
epulz.io.               300     IN      A       87.197.115.180

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: ...

Key fields:

  • TTL (300) = seconds the resolver can cache the answer.
  • ANSWER SECTION = the result.
  • SERVER = which DNS resolver answered.
  • Query time = duration - useful when debugging slow DNS.

Practical commands

# Concise answer (only IP)
$ dig +short epulz.io
87.197.115.180

# All records
$ dig epulz.io ANY

# Trace the whole DNS hierarchy (from root nameservers)
$ dig +trace epulz.io

# Reverse lookup
$ dig -x 87.197.115.180

# Specific resolver
$ dig @8.8.8.8 epulz.io
$ dig @1.1.1.1 epulz.io
$ dig @9.9.9.9 epulz.io

# DNSSEC validation
$ dig +dnssec epulz.io

DNS-over-HTTPS (DoH): when you don't have UDP/53

In some networks (corporate firewalls, mobile data with blocking) the traditional DNS port 53 is blocked. DoH wraps DNS queries into HTTPS requests - they go through everywhere 443 works.

# Cloudflare DoH endpoint
$ curl -s "https://cloudflare-dns.com/dns-query?name=epulz.io&type=A" \
       -H "Accept: application/dns-json" | jq

# Google DoH
$ curl -s "https://dns.google/resolve?name=epulz.io&type=MX" | jq

We also have an online DoH client with a nice UI at - no installation required.

Procedure for "domain doesn't work"

  1. Check the registration. whois yourdomain.com or via the registrar. If expired, nothing else can be fixed.
  2. Check NS records. dig NS yourdomain.com @8.8.8.8. Are the nameservers responsible for the domain returned? Do they match what's in the registrar panel?
  3. Check A record. dig yourdomain.com @8.8.8.8. Does it return the right IP?
  4. Test from an external network (mobile data, VPN, online tool). You yourself may have cached old data.
  5. Check TTL. If you just changed a record, wait at least the original TTL (1-24 hours by default).
  6. Check DNSSEC. If you use it, the signature chain may be broken. dig +dnssec yourdomain.com shows the ad flag on success.

DNS propagation: how long does it take?

"DNS propagation" is a slightly misleading term. DNS doesn't propagate toward you - your resolvers download the answer and cache it according to TTL. Only after TTL expires do they try a new query.

Practical consequences:

  • Planning a migration? Lower the TTL to 60-300 seconds at least 48 hours in advance.
  • The old IP will stay valid for some clients long after the change. Don't shut down the old server immediately.
  • Cloud providers (Cloudflare, AWS Route 53) have fast TTL and cache invalidation, but the end client still has to wait for the TTL of its own resolver.

Conclusion

DNS is the infrastructure glue everyone takes for granted - until it stops working. Regular monitoring of DNS records (A, NS, MX, their TTL and DNSSEC validation) reveals the problem before a customer reports it by phone.

Monitoring of DNS and WHOIS expiry

ePulz.io tracks A/AAAA/MX/NS records and domain registration expiry. 7 days free.

Start monitoring →

Try ePulz.io free - 7 days, no credit card needed.

Create account