Domain Not Resolving? DNS Propagation vs. Bad Records

You just updated your DNS records to point your domain to a new host or CDN. You open your browser, enter your URL, and are met with a bleak screen: DNS_PROBE_FINISHED_NXDOMAIN or Server Not Found.

You contact customer support, and the support representative offers the standard boilerplate response: "Please wait 24 to 48 hours for DNS propagation."

While global DNS propagation is real, waiting 48 hours is almost always a waste of time. In 2026, over 95% of DNS changes propagate across the planet in under 15 minutes. If your domain has not resolved after an hour, you do not have a propagation delay—you have a misconfigured DNS record or an invalid nameserver delegation.

In this guide, we break down how DNS lookup resolution functions, how to query global recursive resolvers directly using command-line tools, and how to spot bad records instantly.

1. What DNS Propagation Actually Means

To understand why domains take time to update, follow what happens when you change an IP address:

1. You edit an A record at your registrar, pointing example.com from IP 1.1.1.1 to IP 2.2.2.2.
2. When a user in Chicago visits your site, their computer asks their local ISP resolver (e.g., Comcast or AT&T).
3. The Comcast resolver checks its cache. If it recently looked up your domain, it still has the old IP (1.1.1.1) stored in memory.
4. The resolver will continue serving the old IP until the TTL (Time to Live) timer expires.
5. Once the TTL reaches zero, the resolver flushes the cache, queries your authoritative nameservers, and fetches the new IP (2.2.2.2).

DNS Propagation is nothing more than waiting for millions of distributed intermediate DNS caches to let their TTL timers run down.

2. The Power of TTL (Time to Live)

Every DNS record has a TTL value specified in seconds:

• TTL = 300 (5 minutes)
• TTL = 3600 (1 hour)
• TTL = 86400 (24 hours)

The Pro Sysadmin Migration Trick:

If you plan to migrate a website or switch hosting providers next Tuesday:

• On Monday: Lower your record's TTL to 300 seconds (5 minutes).
• On Tuesday: When you change the IP address, resolvers around the world will cache the old record for only 5 minutes. Your site will switch to the new host almost instantaneously!
• On Wednesday: Once the migration is stable, raise the TTL back to 3600 or 86400 to reduce query overhead.

3. How to Test DNS Using Terminal Tools (dig and nslookup)

Never rely on your local web browser to test DNS changes. Browsers maintain their own aggressive internal DNS caches, and your home Wi-Fi router maintains another layer of caching.

Open your terminal and query global public DNS resolvers directly using the dig utility.

Test Against Google Public DNS (8.8.8.8):

dig @8.8.8.8 yourdomain.com A +short

Test Against Cloudflare DNS (1.1.1.1):

dig @1.1.1.1 yourdomain.com A +short

Test Against Authoritative Nameservers:

Query your actual authoritative nameservers (the ones assigned by your registrar, like ns1.cloudflare.com):

dig @ns1.cloudflare.com yourdomain.com A +short

Interpreting the Results:

• If your authoritative nameserver returns the new IP: Your record is saved correctly. You simply need to wait for local caches to expire.
• If your authoritative nameserver returns the old IP or nothing: You made a configuration mistake inside your DNS dashboard. No amount of waiting will resolve the issue.

4. The 4 Most Common DNS Configuration Blunders

1. Typo in the Host Field: The Trailing Dot Trap

Some DNS management interfaces require an @ symbol to designate the apex root domain. Others expect you to leave the field completely blank. If your interface expects @ and you typed yourdomain.com, the system may append your domain name automatically, creating:

yourdomain.com.yourdomain.com

Query this in your terminal:

dig yourdomain.com.yourdomain.com +short

If this resolves, you have an accidental double-domain host typo! Edit the record and replace the text with @.

2. Conflicting A and CNAME Records

DNS specification (RFC 1912) states that if a CNAME record exists for a host, no other record of any type (A, TXT, MX) can exist for that same host. If you set a CNAME record on your root domain @, your email (MX records) will break immediately. Use CNAME records only for subdomains (www, api, blog), and use standard A records for the root @.

3. Forgotten www Subdomain

Over 30% of web users still habitually type www.yourdomain.com into browser search bars. If you configured an A record for yourdomain.com but forgot to add a CNAME or A record for www, anyone typing www will receive an NXDOMAIN crash. Always configure both.

4. Broken Nameserver Delegation

Did you purchase your domain at GoDaddy or Namecheap, but set up DNS hosting at Cloudflare or Vercel? You must update your Custom Nameservers at the registrar level. If your registrar is still pointing to its default nameservers, any records you enter inside Cloudflare will sit idle and never be queried by the public internet.

Check your active nameservers via terminal:

whois yourdomain.com | grep -i "name server"

5. How to Flush Your Local DNS Cache

If external tools like whatsmydns.net show that your new IP address has propagated worldwide, but your local machine still refuses to load the site, flush your computer's local DNS resolver cache:

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Windows (run in Administrator Command Prompt):

ipconfig /flushdns

Google Chrome Internal Cache:

Open Chrome, navigate to chrome://net-internals/#dns, and click "Clear host cache".

Armed with dig, TTL foresight, and nameserver verification, you will never spend hours waiting for an error that could be diagnosed and solved in 60 seconds.