🛠️ ITBlogs.pro

DNS Troubleshooting Guide: dig, nslookup and Common Problems

Oct 16, 2026 · Networking · 4 min read

"The website is down" is often "DNS is wrong" in disguise. These commands show what DNS actually returns and where a wrong answer comes from.

Record types you'll meet

Type Purpose
A / AAAA Name → IPv4 / IPv6 address
CNAME Name → another name (alias)
MX Mail servers for the domain
TXT Free text: SPF, DKIM, DMARC, domain verification
NS The authoritative name servers
SOA Zone info (serial number, timers)
PTR IP → name (reverse DNS)
CAA Which CAs may issue certificates

dig: the main tool

Install it if missing: sudo apt install -y dnsutils.

dig example.com                    # full answer with details
dig +short example.com             # just the answer
dig +short example.com AAAA
dig MX example.com +short
dig TXT example.com +short
dig NS example.com +short
dig -x 93.184.216.34 +short        # reverse lookup

Ask a specific server instead of your default resolver:

dig @1.1.1.1 example.com +short        # Cloudflare's public resolver
dig @8.8.8.8 example.com +short        # Google's
dig @ns1.example.com example.com +short   # the authoritative server itself

Follow the whole delegation from the root servers:

dig +trace example.com

In the full output, check status: (NOERROR, NXDOMAIN, SERVFAIL) and the TTL number next to each answer.

nslookup and Windows

nslookup example.com
nslookup example.com 1.1.1.1
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Server 1.1.1.1

What the status means

Status Meaning Check
NOERROR with no answer The name exists but not that record type Right type (A vs AAAA)?
NXDOMAIN The name doesn't exist Typo, record not created, or domain expired
SERVFAIL The resolver could not get a valid answer Broken name servers, expired DNSSEC signatures, lame delegation
REFUSED The server won't answer you You asked a server that isn't a resolver or doesn't serve that zone
Timeout No reply Firewall, wrong server address

The "I changed it but still see the old value" problem

DNS answers are cached for their TTL (time to live, in seconds). Nothing "propagates" on a schedule, because caches simply expire. So:

  1. Ask the authoritative server directly: dig @ns1.example.com example.com +short. If this is right, your change is live, and everyone else is just waiting for a cache.
  2. Compare public resolvers: dig @1.1.1.1 ... and dig @8.8.8.8 .... They may differ briefly.
  3. Clear your own caches:
resolvectl flush-caches                      # Linux (systemd-resolved)
ipconfig /flushdns                           # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS

Browsers keep their own cache too (chrome://net-internals/#dns), and so does your OS /etc/hosts file.

Before a migration, lower the TTL (for example to 300 seconds) a day or two ahead. After the switch, raise it again.

Which resolver is my Linux machine using?

resolvectl status
cat /etc/resolv.conf

On Ubuntu, /etc/resolv.conf usually points to 127.0.0.53, the local systemd-resolved stub. The real upstream servers are shown by resolvectl status.

Common causes of wrong answers

  • /etc/hosts override. A leftover line like 127.0.1.1 mysite.com makes the machine ignore DNS for that name. This is a classic: tests on the server itself look fine while everyone else sees a problem.
  • Cloudflare proxy ("orange cloud"). A proxied record returns Cloudflare's IPs, not your server's, which is correct. Your real IP is hidden. See Cloudflare 521/522 errors.
  • CNAME at the zone apex. example.com itself cannot be a normal CNAME next to other records (use A/AAAA, or your provider's ALIAS/flattening).
  • Stale AAAA record. An old IPv6 address that points nowhere breaks sites for IPv6 users only.
  • Wrong name servers at the registrar. The zone is correct at the DNS host, but the domain is delegated elsewhere. Compare dig NS example.com with where you edit.
  • Short trailing-dot mistakes in zone files: www.example.com without a final . can become www.example.com.example.com..
dig +short MX example.com
dig +short TXT example.com                 # SPF starts with "v=spf1"
dig +short TXT _dmarc.example.com          # DMARC policy
dig +short TXT selector1._domainkey.example.com   # DKIM (selector name varies)
dig +short -x YOUR_MAIL_SERVER_IP          # reverse DNS should match your mail host name

Missing SPF/DKIM/DMARC or mismatched reverse DNS is the usual reason legitimate mail lands in spam.

Quick workflow

  1. dig +short name returns the right IP? If not, ask the authoritative server.
  2. Right IP but the site still fails? It's not DNS. Go to network connectivity diagnosis.
  3. Right on the authoritative server but wrong elsewhere? Wait for the TTL, or flush caches.
digdnsnetworkingtroubleshooting