Domain Not Working? DNS Not Propagating? Here's What's Actually Wrong

You bought a domain. You pointed it at your server. You waited. You refreshed. You waited more. Nothing. Your app is running, you can see it at the IP address, but when you type your domain into a browser you get a blank page, an error, or someone else's website entirely.

Or maybe it was working fine yesterday, and then you changed one DNS setting and now the whole thing is down.

This is one of the most frustrating problems in web development because it feels like it should be simple. You own the domain. You know where the server is. Why can't the internet figure this out?

What DNS actually is, in plain English

DNS is the phone book of the internet. When you type yourapp.com into a browser, your computer doesn't know what that means. It needs an IP address — a number like 143.198.67.42 — to actually find your server.

DNS is the system that translates domain names into IP addresses. When it works, it's invisible. When it doesn't, your domain just... goes nowhere.

The important thing to understand is that DNS is not one thing. It's a chain of systems, and a break at any point in the chain means your domain doesn't work. Your registrar, your nameservers, your DNS records, and your server all have to agree on where traffic should go.

A records vs CNAME records

This is where most of the confusion starts. There are two main types of DNS records, and using the wrong one is incredibly common.

A record: Points your domain directly to an IP address. Use this when you have a VPS or dedicated server (DigitalOcean, Linode, AWS EC2, etc.). You're saying "yourapp.com lives at 143.198.67.42."

CNAME record: Points your domain to another domain name. Use this when your app is hosted on a platform that gives you a subdomain (Vercel, Netlify, Heroku, Render, Railway). You're saying "yourapp.com is the same as my-app.vercel.app, so go look up that address instead."

Common mistake: putting an IP address in a CNAME record, or putting a hostname in an A record. These are different things and they're not interchangeable. If your hosting platform told you to add a CNAME pointing to cname.vercel-dns.com, don't try to look up that IP and use an A record instead. It won't work the same way.

Another common mistake: you can't use a CNAME for the root domain (yourapp.com) on most DNS providers. CNAMEs only work on subdomains like www.yourapp.com. Some providers like Cloudflare have a workaround called "CNAME flattening," but if your provider doesn't support it, you'll need to use an A record for the root domain.

The six most common DNS problems

1. Wrong record type

You used an A record when you needed a CNAME, or vice versa. Check what your hosting provider told you to add. If they gave you a domain name like something.herokudns.com, that's a CNAME. If they gave you an IP address like 76.76.21.21, that's an A record.

2. Wrong IP address in your A record

You set up an A record, but the IP address doesn't match your actual server. This happens when you rebuild a server and get a new IP, or when you copy-paste the wrong number from a tutorial. One wrong digit and your domain points to someone else's server or nowhere at all.

Check: Log into your server and run curl ifconfig.me to see its real IP address. Compare that to what's in your DNS record.

3. Nameservers aren't updated at the registrar

This is the sneakiest one. You set up all your DNS records at Cloudflare (or Route 53, or wherever), but your domain registrar — the place where you actually bought the domain — is still pointing to the old nameservers.

Think of it this way: you wrote your new address in a phone book that nobody is looking at. The registrar is still telling everyone to look in the old phone book.

Check: Go to wherever you bought the domain (GoDaddy, Namecheap, Google Domains, Squarespace, etc.). Look for "Nameservers" in the domain settings. If you're using Cloudflare for DNS, your nameservers should be something like ada.ns.cloudflare.com and bob.ns.cloudflare.com. If they still say something like ns1.godaddy.com, that's the problem.

4. Propagation delay

DNS changes don't take effect instantly. When you update a record, that change has to spread across DNS servers around the world. This is called propagation.

The common advice is "it can take up to 48 hours." In practice, it usually takes 5 to 15 minutes. But if you've been checking every 30 seconds for the last 3 minutes, you might just need to wait a bit.

One thing that slows propagation down: your old DNS record had a high TTL (Time To Live). TTL tells other servers how long to cache your record. If your old TTL was set to 86400 (24 hours), some servers will keep using the old address for up to a full day before checking for updates.

5. www vs non-www mismatch

You set up DNS for yourapp.com but not for www.yourapp.com. Or the other way around. These are technically two different domains, and they each need their own DNS record.

Some visitors type www.yourapp.com out of habit. If that version doesn't have a DNS record, they get an error while yourapp.com works fine. You'll get support emails saying "your site is down" while it looks fine to you.

Fix: Set up both. Typically you'd have an A record for yourapp.com and a CNAME record for www pointing to yourapp.com. Then configure your server to redirect one to the other.

6. Cloudflare proxy is hiding the real IP

More on this below — it's common enough to deserve its own section.

The Cloudflare confusion

A huge number of people use Cloudflare for DNS, and a huge number of those people don't fully understand what Cloudflare's proxy does.

When you add a DNS record in Cloudflare, there's a little cloud icon next to it. It's either orange (proxied) or grey (DNS only).

Grey cloud (DNS only): Cloudflare acts as a normal DNS provider. It tells browsers your server's real IP address. Traffic goes directly from the browser to your server. Simple.

Orange cloud (proxied): Cloudflare puts itself in the middle. Browsers connect to Cloudflare's servers, and Cloudflare forwards the traffic to your server. Your real IP address is hidden. You get DDoS protection and caching, but your server now sees Cloudflare's IP address instead of your visitors' IPs.

This causes problems when:

• Your SSL certificate expects a direct connection. If you have an SSL cert on your server (like from Let's Encrypt) and Cloudflare's proxy is on, the SSL handshake can get confused. You might see infinite redirect loops or "too many redirects" errors. You need to set Cloudflare's SSL mode to "Full (strict)" instead of "Flexible."
• Your app uses websockets. Some Cloudflare plans don't support websockets, or require specific configuration. If your app has real-time features that work on the IP address but break on the domain, the proxy might be interfering.
• You're debugging and can't figure out your real IP. With the proxy on, dig yourapp.com returns Cloudflare's IP, not your server's. This makes troubleshooting confusing because the IP in DNS doesn't match the IP you expect.
• Your hosting platform needs to verify your domain. Some platforms (Vercel, Netlify) need to see a direct DNS record during setup. If the proxy is on during verification, it can fail. Turn the proxy off (grey cloud), let verification complete, then turn it back on if you want it.

If you're not sure whether you need the proxy, start with it off (grey cloud). You can always turn it on later once everything is working.

How to check what's going on

Don't keep refreshing your browser and hoping. Use these tools to see what DNS actually says about your domain:

From your terminal:

dig yoursite.com
dig www.yoursite.com

Look for the "ANSWER SECTION." It will show you the IP address (for A records) or the target domain (for CNAME records) that DNS is currently returning. If there's no answer section, the record doesn't exist yet or hasn't propagated.

Online tools: Sites like dnschecker.org or whatsmydns.net let you check DNS from servers around the world. This tells you if propagation is complete or still in progress.

Checklist:

1. Does dig yoursite.com return the correct IP? If not, the DNS record is wrong or hasn't propagated.
2. Does the IP match your actual server? SSH into your server and run curl ifconfig.me to check.
3. Do both yoursite.com and www.yoursite.com resolve? Check both.
4. Are the nameservers at your registrar pointing to the right DNS provider?
5. If you're using Cloudflare, is the proxy on or off? Try turning it off temporarily to rule it out.

Flush your local DNS cache: Your computer caches DNS lookups. If you changed a record but your browser still shows the old result, your computer might be using cached data.

• Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Windows: ipconfig /flushdns
• Chrome: Go to chrome://net-internals/#dns and click "Clear host cache"

Why AI struggles with DNS problems

DNS troubleshooting is about YOUR specific setup — which registrar you used, which DNS provider you're on, which hosting platform your app runs on, and how all three are connected. There are dozens of registrars, half a dozen popular DNS providers, and hundreds of hosting configurations.

The AI doesn't know which combination you have. So it gives you generic advice: "check your A record" or "wait for propagation." That's not wrong, but it's like telling someone whose car won't start to "check the engine." You need someone who can look at your specific dashboard, see what's actually configured, and tell you which specific thing to change.

DNS also has no error messages. When it's wrong, you just get... nothing. The site doesn't load. There's no log file to paste into the AI. There's no stack trace. The AI is flying blind.