DEV Community: Romail Shah

DNS propagation: how long it really takes

Romail Shah — Wed, 28 Oct 2026 00:04:16 +0000

DNS propagation is the delay between changing a DNS record and everyone being able to see the change. The name's a bit misleading, because nothing actually propagates.

Most people want the short answer, so here it is. If you lowered the TTL on the record to 60 seconds a day beforehand, the change reaches most people within a minute or two. If the record was sitting on a default TTL of 3600, expect roughly an hour. The 24 to 48 hours your hosting company quotes is a safety margin to cover the slowest cache in the chain. You aren't waiting in some queue.

The longer answer is worth reading, though, because it tells you which part of that delay you can control and which part you can't.

What DNS propagation actually is

There's no central registry pushing your A record out to the world's resolvers, and no batch job at 4am updating the internet's address book. DNS is pull based. Nothing gets sent anywhere.

Someone finds out about your record change because something on their end asks for it: their browser, their operating system, or their ISP's resolver. When that question gets asked depends on whether anything along the way still holds a cached answer, and how long it was told to keep it.

That instruction is the TTL, a number of seconds attached to the record by whoever runs the DNS zone. A resolver that fetched your record with a TTL of 3600 will keep handing out the old answer for up to an hour, whatever you've changed since, and however badly you need it gone.

So what people call propagation is thousands of separate caches spread across resolvers and devices, each expiring at a slightly different moment depending on when it first cached the record and what TTL it was given. There's never a clean cutover. Two visitors arriving five minutes after your change can land on two different servers, and both of their setups are behaving exactly as designed.

How long does DNS propagation take?

That comes down almost entirely to the TTL that was on the record before you changed it. The one you set afterwards barely matters. By the time you make the change, every cache already holding your record is counting down on the old value.

TTL before the change	Most visitors see the new record within
60 seconds	1 to 2 minutes
300 seconds	About 5 minutes
3600 seconds (common default)	About 1 hour
14400 seconds	About 4 hours
86400 seconds (old default)	Up to 24 hours

Those figures cover most of your traffic, though there's always a tail: a corporate resolver with a hard minimum TTL, an ISP that caps everything at four hours, a phone that hasn't switched networks in a week. That tail is why the 24 to 48 hour advice sticks around, even though it has nothing to do with how DNS actually works.

In practice, the most important step happens a day before the migration. Lower the TTL to 60 seconds at least 24 hours ahead, and every cache upstream spends that day refreshing on a short clock. Then when you flip the record, they come back for the new answer within about a minute.

Miss that step and you're stuck with whatever the old TTL was, and there's no way to shorten it after the fact.

How DNS actually resolves a domain

A single lookup passes through a chain of stops, and there's a cache at each one.

Browser DNS cache. Chrome's lasts roughly a minute by default. Firefox respects published TTLs more closely. Native mobile apps often keep their own caches that bypass the operating system altogether.
OS DNS cache. macOS uses mDNSResponder, modern Linux usually uses systemd-resolved, and Windows uses the DNS Client service. These respect the TTL on the answers they get, though some enforce a minimum.
Local network resolver. This is usually whatever your network handed you: your home router, your office gateway or your ISP. It has its own cache and doesn't always respect the published TTL. Some ISPs cap TTLs at four hours regardless of what the record says, and corporate networks running BIND, Unbound, pfSense or Pi-hole all make their own decisions.
Recursive resolution up the tree. With nothing cached, the resolver works its way up: root server, then the TLD server for .com or .io, then your authoritative nameserver, and back down. That walk takes milliseconds, and the answer gets cached for whatever TTL it came with.
DoH and DoT resolvers. Browsers using DNS over HTTPS skip your local resolver completely. Firefox uses Cloudflare by default, and Chrome on Android often uses Google. These run their own caches, shared across millions of devices.

So the 24 to 48 hour figure is really just how long the slowest link in that chain takes to let go of its copy. That's usually a third party resolver capping TTL at a day, or a corporate resolver set up years ago by someone who's since left.

Why the 24 to 48 hour number stuck

The number's an oversimplification more than an outright error, and there are a few reasons it's survived this long.

Old TTL defaults are the main one. Back in the 1990s and early 2000s, common TTLs were 86400 or 172800 seconds, and anyone who learned DNS then took those numbers as the window. Actively managed records now usually sit between 60 and 3600, but the advice never caught up.

Some ISPs also used to flush their caches in a daily batch. Change your record just before one and it felt instant. Change it just after and it felt like a full day. From the outside, the delay looked completely random.

It also closes support tickets. If a customer changes DNS and complains straight away, the cheapest answer is to tell them to wait 24 to 48 hours. By then the problem has usually fixed itself or stopped mattering, and as support economics go, that's hard to beat.

And the long tail is real. Even with sensible TTLs, there's always one cache somewhere that won't update for a day, and the polite fiction covers that without anyone having to explain it.

So it's a load bearing approximation. The trouble starts when you take it literally and plan your migration around waiting it out.

What actually controls when your change is visible

There are five layers, ordered from the one you control to the ones you really don't.

Layer 1: TTL on your record (you control this)

This is the only dial you can actually turn. Set it to 60 seconds at least 24 hours before the change, flip the record, then raise it back to 3600 or higher once the new server has been stable for a couple of days. Leaving it on 60 forever just adds unnecessary query load and latency.

Layer 2: Your authoritative nameservers (mostly out of your control)

Your DNS provider might not push changes across its own servers instantly. Cloudflare and Route 53 are effectively immediate, but some smaller registrars take one to five minutes for a change made in the admin panel to show up on all their nameservers. Give it two minutes, then check with dig +trace example.com before you go looking for a bigger problem.

Layer 3: ISP and public resolver caches (out of your control)

The big public resolvers, Cloudflare on 1.1.1.1, Google on 8.8.8.8 and Quad9 on 9.9.9.9, respect TTLs well. ISP resolvers are more of a mixed bag. Some respect the published value, some cap it, and some have quirks you'll only find written up in an old forum thread. Corporate resolvers do whatever their IT team set up, which often isn't what the record asked for.

Layer 4: Browser DNS caches (out of your control)

Chrome's lasts about a minute, Safari's is similar, and Firefox respects TTLs more closely. It's a small layer but the most noticeable one: "it works on my phone but not in this tab" is nearly always a stale browser cache. Clearing it at chrome://net-internals/#dns fixes it for that person, in that browser, one time.

Layer 5: DNS over HTTPS providers (out of your control)

A browser using DoH goes around both the ISP resolver and the corporate one, talking straight to a third party. That's why asking a client's IT team to flush their cache sometimes changes nothing at all. They control the corporate resolver, but the browser is talking to Cloudflare, and nobody at the company knows.

How to check DNS propagation

Don't test by loading the site in your browser. That adds two more caches, your browser's and your operating system's, on top of the resolver you're actually trying to look at. Query resolvers directly instead.

# Ask two large public resolvers what they currently hold
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +short

# Watch the full walk from the root servers down
dig +trace example.com

# Ask your authoritative nameserver directly, bypassing every cache
dig @ns1.yourprovider.com example.com +short

If you're on Windows without dig, nslookup example.com 1.1.1.1 will get you most of the way.

That last command is the one that matters most during a migration. Your authoritative nameserver is the source of truth, so if it returns the new IP, your change is live and everything after that is just caching. For a worldwide picture, whatsmydns.net queries 20 to 50 resolvers at once.

Expect them to disagree for a while. Mixed results are completely normal partway through a TTL window.

Can you speed up DNS propagation?

Once the change is made, no, and no tool can either. You can't reach into someone else's resolver and expire their cache. Anything promising to force global propagation is really just a checker with a refresh button.

What does work is preparation. Lowering the TTL 24 hours ahead is really the whole game, and it's the difference between a one minute cutover and an all day one.

The only caches you can actually flush are your own:

Windows: ipconfig /flushdns
macOS: sudo dscacheutil -flushcache then sudo killall -HUP mDNSResponder
Linux (systemd): sudo resolvectl flush-caches
Chrome: visit chrome://net-internals/#dns and clear the host cache

That's useful for checking your own work, and no help at all for the client whose office resolver is the actual problem. The full set of commands, including Firefox, iPhone and Android, is in how to flush DNS.

What to do instead of waiting

Once you accept that the delay is just caches expiring, your migration process changes. You stop waiting, and you test the new server while DNS still points at the old one.

I should be upfront about a conflict of interest here: I built a free tool for this. DNS Previewer creates a temporary subdomain that proxies your new server using the correct Host header and TLS SNI for your real domain, so the server responds exactly as it will after the change. You can open it on any device before touching a record. SkipDNS is the established paid tool that does the same job, and I keep an honest comparison of the two, including the parts where theirs is better. Editing your hosts file works too, with limitations worth knowing.

Here's the process itself:

Lower the TTL to 60 seconds at least 24 hours before the migration. It's the most important thing you control, and the only one you can't fix later.
Test the new server under your real domain before changing any records, so vhost and certificate problems turn up before your visitors find them. Certificates are the awkward one here, because most authorities want the hostname pointing at the new machine before they will issue one, which is the deadlock behind ERR_SSL_PROTOCOL_ERROR on a fresh server.
Flip the record once the new server responds correctly. The cutover itself should feel boring.
Don't rely on a single checker. Test from the client's actual network too, since that's where stale cache problems tend to hide.
Raise the TTL back to 3600 or higher after 48 stable hours.
Write down the old IP and test your rollback before you need it at 4am.

Waiting to see what happens is how you end up with the 3am phone call. Testing before you flip catches the same problems without any of your visitors being involved.

The short version

There's no single process running somewhere that you can check the status of. DNS propagation is the sum of every cache between your record and your visitor, each expiring on its own clock, with TTL as the only input you control.

Set a low TTL a day in advance, check the new server before you change anything, query resolvers directly instead of reloading a browser tab, and accept that the long tail of stale caches is nobody's fault. That's simply how the protocol was designed to work.

Once you understand what's actually going on, you stop waiting for it.

Originally published on the DNS Previewer blog.

ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it

Romail Shah — Wed, 28 Oct 2026 00:03:08 +0000

You typed an address, the page never appeared, and Chrome replaced it with "This site can't provide a secure connection" and the line ERR_SSL_PROTOCOL_ERROR.

Nothing loaded because nothing was ever sent. HTTPS starts with a handshake: your browser and the server agree which version of TLS they'll speak, pick a cipher, and the server proves its identity with a certificate. Only after all that does a single byte of the page move. This error means the handshake fell over.

There's a quick way to tell whose problem it is. Open two or three other HTTPS sites. If they load, the fault is with the site you're trying to reach, and no setting on your computer will fix it. If they all fail the same way, it's your side, and the section below will sort it.

What the error actually says

Chrome keeps a list of network error codes, and this one is defined as "An SSL protocol error occurred", numbered -107. On screen it comes out as the site name followed by "sent an invalid response."

There's a close relative worth knowing, because the fix is different. ERR_SSL_VERSION_OR_CIPHER_MISMATCH is defined as "The client and server don't support a common SSL protocol version or cipher suite", and its page says the site "uses an unsupported protocol." That one is nearly always an old server offering only old TLS. If that's what you're seeing, skip to cause 2.

Other browsers describe the same failure in their own words. Safari says it can't establish a secure connection, Firefox talks about a secure connection failing. It's the same handshake, failing the same way.

If you're the visitor

Four things are worth doing, roughly in this order.

Check your clock. Certificates are only valid between two dates, so a machine with the wrong date rejects good certificates. Chrome says this itself on its error pages: to establish a secure connection, your clock needs to be set correctly. Turn on automatic time in your system settings, especially on a computer that's been switched off for months.

Turn off HTTPS scanning in your antivirus for a moment. Security suites often inspect encrypted traffic by sitting in the middle of it, and when that goes wrong it breaks handshakes exactly like this. Look for a setting called HTTPS scanning, SSL scanning or encrypted connection scanning. If the site loads with it off, you've found your culprit and the vendor's support is the next stop.

Try a different network. Work wifi, a VPN or a captive portal in a hotel can all intercept traffic. Loading the site on your phone over mobile data takes thirty seconds and tells you whether the network is at fault.

Try another browser. If Chrome fails and Firefox works, the problem is local to Chrome's setup, and a new profile or a reset usually clears it.

One thing you cannot do is click through. A certificate warning offers an Advanced link because the connection worked and only the identity is questionable. Here there's no connection to continue into. Some sites will still load if you type http:// in front, which proves the server is alive and its HTTPS is broken, but don't log in or type anything private into a page loaded that way.

If the site is yours

Everything below happens on the server, and in my experience it's nearly always one of five things.

Cause 1: no certificate for that hostname yet

This is the one that catches migrations. Certificates don't travel with your files. Copy a site to a new server and that machine has no certificate for your domain, so it either serves nothing on 443 or falls back to a default certificate for its own hostname.

The same thing happens on a server hosting several sites. Because one IP address can hold many sites, the browser has to say which hostname it wants during the handshake, using SNI. If the server has no certificate matching that name, the handshake fails. nginx's documentation is blunt about the limits here: for maximum interoperability with clients that don't use SNI, virtual servers with different certificates should listen on different IP addresses.

Check what the server actually presents:

openssl s_client -connect example.com:443 -servername example.com

The -servername option sets the SNI value in the request, which is how you test one specific site on a shared IP. Look at the subject and issuer that come back. If they name a different host, or you get no certificate at all, that's your answer.

Cause 2: the server only speaks old TLS

TLS 1.0 and 1.1 are no longer acceptable. RFC 8996, published in March 2021, is unambiguous: "TLS 1.0 MUST NOT be used" and "TLS 1.1 MUST NOT be used". Browsers followed, so a server still offering only those versions now fails the handshake, usually with the mismatch error rather than this one.

Both major web servers already default to something sane. nginx's ssl_protocols defaults to TLSv1.2 TLSv1.3, and Apache's SSLProtocol defaults to all -SSLv3. The trouble comes from old config files copied forward from a server built years ago, where someone pinned an explicit list. Find the line and make it current:

ssl_protocols TLSv1.2 TLSv1.3;

You can prove which versions a server accepts by asking for one:

openssl s_client -connect example.com:443 -tls1_2

If that succeeds and the browser still fails, the version isn't your problem.

Cause 3: nothing is serving HTTPS on port 443

Obvious once you see it, invisible until you check. The web server may only be listening on port 80, or a firewall may be blocking 443, or the service crashed and only the HTTP one came back.

curl -vI https://example.com

A connection refused means nothing is listening. A timeout usually means a firewall is swallowing the packets. Getting as far as a TLS error means the port is open and the problem is in the handshake itself, which sends you back to causes 1 and 2.

There's a stranger version of this: plain HTTP being served on port 443. The browser starts a TLS handshake, receives what looks like an HTTP response instead, and gives up. That happens when a listen 443 block is missing the ssl flag.

Cause 4: Cloudflare set to the wrong SSL mode

If Cloudflare sits in front of your site, its encryption mode has to match what your origin server can actually do. Cloudflare's documentation describes Full mode as Cloudflare matching the visitor's protocol when it connects to the origin, using HTTPS without validating the origin's certificate, while Full (strict) adds validation of that certificate.

So a mode set to Full or Full (strict) against an origin with no working HTTPS produces errors, and Flexible exists for origins that can't do TLS at all. After a migration, the mode that suited the old server often doesn't suit the new one. Check the origin directly, bypassing Cloudflare, before changing the mode:

curl -vI https://203.0.113.42 --resolve example.com:443:203.0.113.42

Cause 5: a broken or incomplete certificate chain

Your certificate is usually signed by an intermediate, which is signed by a root the browser trusts. Leave the intermediate out and some clients can't connect the two.

nginx expects them in one file, in a specific order, and says so plainly: if intermediate certificates should be specified in addition to a primary certificate, they should be specified in the same file, with the primary certificate first. Get the order wrong, or paste only the leaf, and you'll see failures that come and go depending on what each client already has cached.

openssl s_client -connect example.com:443 -servername example.com -showcerts

That prints the full list the server sends, which is exactly what you need to compare against what your certificate authority gave you.

When it started right after a move

Then it's almost certainly cause 1, and the timing is the giveaway.

The certificate on the old server covers your domain. The new server has nothing, and it usually can't get anything, because most certificate authorities want to see the hostname pointing at the machine before they'll issue one. So you're stuck between two steps: DNS can't move until the site works, and the certificate can't be issued until DNS moves.

There are two honest ways out. Use a DNS-based validation challenge, which proves you own the domain without pointing traffic anywhere, so the certificate can be issued before the move. Or check the site over a preview link while the certificate question is still open.

DNS Previewer is the second one. It loads your site from the new server under its real domain name, and you can tell it to connect to your server over HTTP, HTTPS, or to fall back automatically, which is what you want while the new machine has no valid certificate yet. So you can confirm the site itself works, sort the certificate out, then change DNS. The WordPress migration checklist has the rest of the pre-flight list, and checking the certificate covers the real domain is item one on it for this exact reason.

Two related errors turn up in the same week as this one. A 502 Bad Gateway means the handshake worked and the thing behind your web server didn't answer. An error establishing a database connection means the site is serving fine and the database details are stale. Different layers, different fixes.

The order I'd work through it

Does any other HTTPS site load? If yes, stop looking at your computer.
If nothing loads: clock, antivirus HTTPS scanning, then a different network.
If the site is yours, run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com and read the certificate it returns.
Wrong name on the certificate, or no certificate: issue one that covers the hostname.
Nothing listening at all: check the web server is up, listen 443 ssl is present, and the firewall allows it.
Mismatch error rather than this one: raise the TLS versions to 1.2 and 1.3.
Cloudflare in front: compare its SSL mode against what the origin can really do.

Most of the time it's a certificate that doesn't cover the name being asked for, and it takes longer to read the error than to fix it.

Originally published on the DNS Previewer blog.

How to preview a site on a new server without editing the hosts file

Romail Shah — Fri, 23 Oct 2026 23:50:16 +0000

Every migration ends up in the same spot. The files are on the new server, the database is imported, and now you've got to work out whether it actually works before you point DNS at it and find out in public.

The usual answer is to edit your hosts file. It's a good answer. It's also older than DNS itself, and it has limits that are easy to forget until they bite.

What editing the hosts file actually does

Before your computer asks a DNS server where example.com lives, it checks a plain text file on disk. If that file has a line for the hostname, the lookup stops right there and nothing goes out over the network.

You'll find it here:

Windows: C:\Windows\System32\drivers\etc\hosts
macOS and Linux: /etc/hosts

Both are protected system files. On Windows you need to run your editor as administrator, and on macOS or Linux you need sudo.

It's one mapping per line, with the IP address first:

203.0.113.42    example.com
203.0.113.42    www.example.com

The reason this trick works at all comes down to what your browser sends. It still sends Host: example.com in the request, and the TLS handshake still carries example.com as the SNI value. So the new server sees the real domain name, picks the right virtual host and serves the right certificate, exactly as it would after a real DNS change.

That's why editing the hosts file beats typing the server's IP address into the address bar. If you visit http://203.0.113.42 directly, the browser sends Host: 203.0.113.42, and the server has no idea which site you're after. You get the default virtual host, which is usually an Apache welcome page, a 404, or someone else's website on the same box. People see that and assume the migration failed. It didn't. They just asked the wrong question.

So the hosts file gets the technical part right. Its problems are all practical ones.

Where the hosts file runs out of road

It only works on the machine you edited

This is the biggest problem by far. A hosts entry is local. Your client can't see what you see, your colleague can't either, and there's no way to email it to anyone.

To bring even one other person along, you'd have to walk them through opening a protected system file with administrator rights on their own computer. On a managed work laptop that's often blocked by policy, so no amount of patience on the call is going to get you there.

There are no wildcards

The hosts file matches exact hostnames, and there's no syntax for *.example.com. If you're migrating a WordPress multisite, or anything with blog., shop., app. and a few others, you need a line for every single one, and you need the full list before you start.

Miss one and you get a confusing, half-broken result, where some of the site comes from the new server and some quietly comes from the old one.

Phones and tablets are out

There's no supported way to edit the hosts file on a stock iPhone or Android device. Unless you root or jailbreak it, you simply can't test on mobile this way.

That hurts more than it sounds, because mobile is where layouts break, where buttons end up too close together, and where a slow new server is most obvious.

Firefox may ignore it completely

Firefox enables DNS over HTTPS, which looks names up inside the browser over an encrypted connection to a DNS provider. When that's on, the lookup never reaches your operating system, so your hosts file gets skipped entirely. Your entry can be correct and saved and still be completely ignored.

Mozilla has been tracking support for local address overrides under DoH in bug 1453207 for years. Chrome behaves differently here and generally still honours the file, because it checks the system resolver for local entries. That's why the same test can pass in one browser and fail in another on the same machine.

If you're relying on the hosts file, check whether DoH is switched on before you draw any conclusions about the server.

Caches will lie to you for a while

Editing the file doesn't clear what your system already remembers:

Windows: ipconfig /flushdns
macOS: sudo dscacheutil -flushcache then sudo killall -HUP mDNSResponder
Chrome, separately: visit chrome://net-internals/#dns and clear the host cache

Skip this and you can easily lose twenty minutes debugging a server that was fine all along. The commands for Linux, Firefox and phones are in how to flush DNS.

You have to remember to take it out

A forgotten hosts entry makes for a really nasty bug. You finish the migration, DNS changes properly, everyone moves on, and your own machine keeps pointing at the old IP because the line never got removed.

Weeks later the site looks frozen or broken, but only for you, and nobody else can reproduce it. It's the kind of problem that can swallow a whole afternoon before anyone thinks to check.

How to preview a site on a new server without touching the hosts file

The alternative is to take the same trick off your machine and put it behind a URL.

A preview link works as a reverse proxy. You give it your domain and the new server's IP address, and it hands you back a link on a subdomain, something like x7k3p.dnspreviewer.com. When you open that link, the proxy connects to your new server and sends Host: example.com along with it, plus the matching SNI on the TLS connection.

So the new server sees the same request it would after a real DNS change. You get the right virtual host and the right certificate behaviour, which is the whole point of the hosts file trick, only now it's a link.

That one change fixes most of the list above in one go. You can send a link to a client. It works on a phone without any setup. It doesn't need administrator rights, it doesn't matter whether someone's using Firefox with DoH, and there's nothing left behind on anyone's machine to forget about.

Wildcards stop being a problem too, because the proxy can cover a whole domain and all its subdomains, so you're not listing them out by hand.

DNS Previewer does this for free, wildcards included. You can also choose whether the connection to your server uses HTTPS, HTTP or falls back automatically, which helps when the new server doesn't have a valid certificate for the domain yet. With a free account you can also put a password on a link, so it isn't open to anyone who gets hold of the URL, and create links that never expire. That HTTP fallback matters more than it sounds, because a new server without a certificate for your domain yet will otherwise greet you with ERR_SSL_PROTOCOL_ERROR. If you've come across SkipDNS, the paid tool that does the same job, here's how DNS Previewer compares with SkipDNS.

The honest limitations

A preview link is a proxy, so your traffic passes through a third party. If you work under rules that forbid that, or you're testing something involving genuinely sensitive data, the hosts file keeps everything on your own machine, and that's a real advantage.

One more thing, and it applies to both approaches equally. If your domain normally sits behind a CDN like Cloudflare, pointing either a hosts entry or a preview link at your origin server only tests the origin. The edge isn't involved, so page rules, caching behaviour and edge redirects aren't being tested. Plan a separate check for those once you've cut over. The WordPress migration checklist covers the CDN and everything else worth checking around the switch.

When the hosts file is still the right tool

It hasn't been made obsolete. It's still the right choice when:

You need a quick check on one machine, for one hostname, and nobody else needs to see it
You're working somewhere that won't allow traffic through an outside service
You need to test something that isn't plain HTTP, like a mail server or a service on an unusual port, where a web proxy can't help

For everything else, and especially anything a client has to sign off on, the real sticking point is who can see it. The hosts file can't leave your laptop, and a migration is rarely something you approve on your own.

The short version

Editing the hosts file sends the right Host header and the right SNI, so it genuinely tests the new server under your real domain. That part's correct and always has been.

What it can't do is travel. One machine, admin rights needed, exact hostnames only, no phones, and Firefox might skip it. If you're the only person who needs to see the new server, it's fine. The moment someone else needs to look, you want a link.

Originally published on the DNS Previewer blog.