Why Your New Domain Is Not Loading Yet, and What TTL Means

You bought a domain, pointed it at your new host, and typed it into the browser. Instead of your site, you get the registrar's parking page, or Chrome's "This site can't be reached" with the code DNS_PROBE_FINISHED_NXDOMAIN. Your friend on their phone sees the new site fine. You refresh twenty times and nothing changes.

The host's help page says "please allow 24 to 48 hours for DNS propagation", which is both a little bit true and mostly unhelpful. It does not tell you what is actually waiting, or whether you can do anything about it. Once you understand one small number attached to every DNS record, the TTL, the waiting stops being mysterious and you can usually see the new site within minutes, not days.

Nothing is propagating. Copies are expiring.

The word "propagation" suggests your change is spreading across the internet like a wave. That is not what happens. When you edit a record at your DNS provider, the change is live on their servers almost immediately. What lags behind are the copies other computers saved earlier.

When your laptop looks up a domain, it usually asks a resolver run by your internet provider, or a public one such as Google's 8.8.8.8 or Cloudflare's 1.1.1.1. That resolver asks the authoritative servers for your domain, gets the answer, and keeps a copy so it does not have to ask again for every visitor. Your operating system keeps its own copy. So does your browser, briefly. Your router may too.

Each of those copies is kept for as long as the record's TTL says, short for time to live, measured in seconds. A TTL of 3600 means "you may reuse this answer for one hour". If your old record had a TTL of 86400, a resolver that looked it up just before your change can keep serving the old address for a full day, and it is behaving correctly when it does.

That is why your friend sees the new site and you do not. Their phone asked a different resolver, one that had no saved copy, or whose copy had already expired.

Where the "48 hours" figure really comes from

Changing an A record, which maps a name to an IP address, is usually quick, because the old TTL is often an hour or less. Changing your nameservers is a different job, and it explains the scary number.

When you switch nameservers at your registrar, the update happens one level up, in the registry for your domain ending. For .com and .net, the delegation records the registry hands out carry a TTL of 172800 seconds. That is exactly 48 hours. A resolver that cached your old nameservers can, in the worst case, keep using them for two days. Most resolvers refresh well before that in practice, and I have seen many switches settle in under an hour, but the 48 hour figure is a real ceiling, not something support teams invented.

So the first useful question when a domain "isn't working" is: did I change records, or did I change nameservers? The answer tells you whether you are looking at minutes or possibly a weekend.

The trap of visiting too early

There is one more cache that catches beginners. If you typed your domain into a browser before any record existed, the resolver may have stored the fact that the name did not exist. This is called negative caching, and how long it lasts is set by a value in your domain's SOA record, often somewhere between five minutes and a few hours. Visiting "just to check" ten minutes after buying the domain can lock in a "does not exist" answer that outlives your actual fix.

How to see what is really going on

Rather than refreshing a browser, ask the resolvers directly. On Windows, open Command Prompt; on macOS or Linux, open Terminal.

Run nslookup yourdomain.com 1.1.1.1 and then nslookup yourdomain.com 8.8.8.8. If both return your new host's IP address, the public internet has caught up and the problem is local to your machine. If they disagree, one of them still has an old copy. On macOS and Linux, dig yourdomain.com shows the answer plus the remaining TTL counting down, which tells you exactly how long that copy has left.

To clear your own machine's copy, run ipconfig /flushdns on Windows. On recent macOS versions, run sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder. In Chrome you can also visit chrome://net-internals/#dns and press the clear button. Both Google and Cloudflare offer a public page to ask their resolvers to drop a cached name, which is worth knowing if most of your visitors use one of them.

Two other issues look like DNS but are not. If the bare domain works and the www version does not, you are probably missing a record for www, usually a CNAME pointing to the bare name or to your host. And if the site loads with a "Your connection is not private" warning for the first few minutes, your host is likely still waiting to issue an HTTPS certificate, which many hosts can only do once the DNS points at them. That one fixes itself; give it about fifteen minutes before contacting support.

Plan the next switch so nobody waits

The real lesson of TTL is that you can prepare for a change. If you are moving an existing site to a new host, this order avoids the long overlap almost entirely:

1. Look up the current TTL on your A record, for example 14400 seconds, which is four hours.
2. Lower it to 300 seconds, five minutes, at least one full old TTL before the move. With 14400, do it the afternoon before.
3. On moving day, change the A record to the new host's IP. Resolvers now hold old copies for five minutes at most.
4. Keep the old host running for a day anyway, for the odd resolver that ignores short TTLs.
5. Once traffic has clearly moved, raise the TTL back to 3600 or higher so lookups stay fast and cheap.

This does not help with nameserver changes, since you do not control the registry's 48 hour value. For those, change nameservers early, days before launch, and keep the records identical at both providers during the overlap.

If you are still choosing where your site should live, read our guide on choosing hosting and a domain first, because a registrar with a clear DNS panel saves a lot of guessing. And if the site finally loads but looks wrong, that is usually a separate problem, covered in why a site looks fine locally and broken once deployed.

One thing to check this week

Open your DNS settings and write down the TTL on your main A record and your www record. If either is above 3600 and you expect to change hosts this year, note the two step plan above next to it. If your domain is brand new, resist visiting it until your records are in place, then confirm with nslookup against 1.1.1.1 before you open a browser. More plain explanations like this one are in our web basics section.