DNS Server Not Responding? How to Check DNS Records and Fix It

DNS server not responding: the quick fixes

If nothing resolves from one device, run these in order before blaming the website:

• Restart the router and the device — the cheapest fix and the one that works most often.
• Flush the local resolver cache: ipconfig /flushdns on Windows, dscacheutil on macOS.
• Switch to a known public resolver such as 8.8.8.8 or 1.1.1.1 and test the same name again.
• Compare your ISP resolver against a remote one with the free [[DNS lookup tool|/dns-lookup]]: if remote resolvers answer but yours does not, the problem is your resolver.

ipconfig /flushdns
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

What DNS records do

Every domain publishes a set of records. The ones that matter day to day:

• A — maps a name to an IPv4 address (example.com → 93.184.215.14).
• AAAA — maps a name to an IPv6 address (example.com → 2606:2800:220:1:...).
• CAA — lists the certificate authorities allowed to issue TLS certificates for the domain.
• CNAME — aliases one name to another (www.example.com → example.com).
• MX — the mail servers that accept mail for the domain, with priority numbers.
• NS — the authoritative name servers for the domain.
• TXT — arbitrary text records, commonly SPF, DKIM and domain verification.
• SOA — start of authority: primary name server, contact, record version.
• PTR — reverse mapping from an IP back to a name, used mainly by mail and logging.

How a DNS lookup travels

One query can cross several servers: your device asks its configured resolver, the resolver walks the delegation from root to top-level domain to the authoritative name servers, and each answer is cached for the record TTL. Most of the time the resolver already knows the answer, which is why a lookup can return in milliseconds.

When to check DNS records

• A site stopped resolving: check A and AAAA against your hosting provider's addresses.
• You moved hosts or DNS providers: confirm NS points to the new provider and the zone actually moved.
• Email is bouncing: verify MX, and that TXT still carries the right SPF and DKIM entries.
• You changed something: old records can linger in caches, and an external lookup shows what visitors actually get.
• Diagnosing an outage: DNS misconfiguration is one of the most common causes of "the site is down" reports.

Propagation, TTL, and why answers differ by region

Record changes don't spread instantly. Every resolver caches answers for the TTL (time-to-live) the record specifies, anywhere from minutes to days. Different resolvers therefore return different answers at the same moment, and after a change some visitors see the new record while others still see the old one.

That's why one lookup from one resolver can mislead you. The tool here asks the resolver used by a remote Globalping probe in the region you choose, so you can compare what DNS looks like from the US, Europe and Asia Pacific.

DNS lookups from your machine

nslookup works everywhere. dig is available on macOS, Linux and modern Windows.

dig example.com A
dig example.com CAA
dig example.com MX
dig @8.8.8.8 example.com AAAA

nslookup -type=MX example.com
nslookup example.com

dig -x 93.184.215.14
nslookup 93.184.215.14

Summary: compare resolvers, then trust the difference

Run a DNS lookup from the region that matters, compare it against a second resolver, and only then conclude anything about a domain. Records have a TTL for a reason: mixed answers during propagation are normal, and the fix is usually to wait, lower the TTL, or find the stale server. For the rest of the stack, a website speed test shows whether DNS is actually slowing a page down.

• Ask for the exact record type — A for the site, MX for mail, TXT for SPF and DKIM.
• No CAA record is a valid result, not an error.
• Different resolvers can legitimately disagree until caches expire.