How long does a DNS change take? Propagation time, TTL, and migration guide

The difference between changing nameservers and changing an A or CNAME record

A nameserver change changes which servers manage the domain’s DNS and is communicated through the registrar to the domain extension’s registry; changing a single A or CNAME record affects only that record. The first generally takes longer because it passes through more layers.

An A record connects a domain to an IPv4 address, while a CNAME record connects one name to another. When only an A record changes, the expected wait depends on its old TTL, which can be lowered in advance in the DNS panel. For a nameserver change, the registrar must first process the change in the parent zone; Cloudflare’s domain setup documentation states that the registrar can take up to 24 hours to update nameservers. The TTL of NS records in the parent zone is also controlled by the extension’s registry rather than the domain owner.

A nameserver change is not the same as a domain transfer. A transfer changes the company where the domain is registered; with a nameserver change, the domain stays at the same company and only its DNS is managed elsewhere. Transfer steps are explained separately in the domain transfer guide . Another important warning in Cloudflare’s documentation is that if DNSSEC is enabled for the domain, it must be disabled at the registrar before changing nameservers; otherwise the domain may become completely unreachable.

Shortening DNS propagation time: Lower TTL in advance

The most effective way to shorten DNS propagation time is to lower the relevant records’ TTL values before the change and wait for the old high value to expire from caches. The subsequent change then reaches most resolvers within the new, shorter TTL period.

This technique appears in the standard itself: RFC 1034 states that if a change is anticipated, TTL can be lowered before it and restored to its old value afterward. Google’s hosting migration documentation also recommends lowering TTL to a low value such as a few hours at least a week before migration. We follow this sequence in our migration process:

1. Note the current records’ TTL values; the panel shows them in seconds.
2. Lower TTL for the A, CNAME, and, if necessary, MX records that will change.
3. Wait at least as long as the old TTL; the old long value expires from caches only at the end of that period.
4. Switch the record to the new server and keep both servers running together for a while.
5. Raise TTL to its former level after the transition has settled.

Cloudflare’s TTL documentation clearly explains the balance: a long TTL speeds queries by increasing the chance of results coming from cache, but delays record updates taking effect. According to the same document, proxied records in Cloudflare have a TTL of 300 seconds that cannot be changed; local DNS caching can still make a change take longer than five minutes to appear.

Website not opening after pointing the domain: Possible causes

If the website does not open at all after pointing the domain, the cause is usually a missing or incorrect record rather than a wait. With cache delays, either the old or new website opens; if neither opens, something is missing in the records or responding server.

Common causes include:

• The new DNS panel lacks an A record for the root domain or a record for www. Cloudflare’s documentation states that visitors may see DNS_PROBE_FINISHED_NXDOMAIN if the transition is made before correct records are configured.
• The A record points to an old, incorrect, or mistyped IP address.
• The domain has not been added to the hosting account on the new server; the server cannot find a website to handle the request.
• Nameserver names have been entered incompletely or incorrectly in the registrar’s panel.
• Nameservers were changed while DNSSEC was enabled.
• A “not found” response received during the transition was cached.

The last item is often overlooked: if the domain failed to resolve briefly, this negative response is also cached for a while. Microsoft’s ipconfig documentationstates that the cache-clearing parameter also removes negative records. If the website opens but the browser displays a security warning, the problem is SSL rather than DNS. The general error picture is covered in the reasons a website will not open article.

How to clear DNS caches: Device, browser, and Google Public DNS

Someone who keeps seeing the old website on their device can see the new record sooner by clearing the operating system and browser caches. This affects only that device; it does not change the service provider’s cache or what other visitors see.

Operating system and browser cache

On Windows, running ipconfig /flushdns at the command prompt clears the DNS client cache; Microsoft’s documentation gives this command as an example for troubleshooting name resolution. On macOS and Linux, the command varies by version and resolver service; obtain the current command from the relevant operating system’s documentation. The browser’s page cache can also display a copy of the old website; completely closing and reopening the browser refreshes this layer.

Since the modem can also store results, testing over mobile data is the easiest comparison. For a technical check, query a specific DNS server directly with a command such as nslookup and compare the returned IP address with the new server’s address.

Google Public DNS cache-clearing tool

Google Public DNS’s official Flush Cache toolrefreshes an old record in Google’s resolver before it expires. According to Google’s FAQ, the tool works for common record types and most domains; it does not require proof of domain ownership but does require reCAPTCHA verification. Pay attention to the following when using it:

• If the registrar or DNS service changed recently, flush the main domain first, then subdomains; the tool page recommends this order.
• If old CNAME responses are returned, flush the CNAME type for each CNAME name, starting with the name at the end of the chain.
• Domains using EDNS Client Subnet for geographic routing cannot be flushed with this tool.
• Domains containing Turkish characters can be entered only in punycode form.

The tool affects only Google Public DNS; it does not touch service provider or mobile carrier caches. Nevertheless, it is a practical way to test that the new record was entered correctly.

Avoiding lost email during migration: Preserve MX records

To avoid email interruption during hosting migration, MX records and other email-related records must be copied exactly to the new DNS panel. If MX is missing from the new panel after a nameserver change, incoming mail cannot locate the server where it should be delivered.

An MX record specifies which server receives email sent to the domain. Cloudflare’s setup documentation explicitly includes SPF, DKIM, and DMARC alongside MX among records to review before switching. If these authentication records are missing, messages may land in recipients’ spam folders or be rejected even if they are sent.

Before switching, list the following records in the old panel:

• MX records and their priority values
• TXT (or CNAME) records used for SPF, DKIM, and DMARC
• Records for mail, webmail, and similar email subdomains
• Other TXT records added by the email service for verification

The important distinction is where email is hosted. If email uses a separate business service, leave MX alone and change only the website’s A record. If email is on the old hosting, closing the old account also closes the mailboxes; plan mailbox and message migration separately.

How is an SSL certificate installed on the new server?

On the new server, an SSL certificate is installed after the domain points there or through DNS verification; the certificate on the old server does not move automatically. This is a common reason for certificate warnings during the first hours of the transition.

According to free certificate provider Let’s Encrypt’s challenge types documentation , with HTTP-01 verification, the certificate client places a file on the server to be read through the domain on port 80. Since verification uses the domain’s address, this method cannot succeed on the new server while DNS still points to the old one. With DNS-01 verification, a domain-specific TXT record is added; the documentation states that this method works even when the web server is not publicly accessible.

After migration, check that the certificate covers both www and non-www names, automatic renewal is enabled on the new server, and old http links within the website do not produce mixed content warnings. If a warning continues, first verify that DNS actually points to the new server, then request the certificate again. Other causes of the warning are explained in the “Your connection is not private” error guide .

Common DNS transition mistakes and the correct approach

Most DNS transition problems result from the order of steps rather than the duration. In common practice, changes are made first and people wait when a problem appears; in our migration process, records are inventoried and TTL lowered first, followed by the transition.

Another common mistake is leaving every problem to wait because “DNS has not propagated yet”. If the same error occurs from different networks after the old TTL has expired, waiting will not solve it.

DNS change checklist

In a planned transition, how long a DNS change takes stops being a problem, because the waiting period is known beforehand and keeping both servers running minimizes interruption risk for visitors. We follow this sequence in our migration process:

1. Export every record from the old DNS panel or retain screenshots.
2. Lower TTL for changing records and wait for the old TTL duration.
3. Move the website and database to the new server and add the domain to the hosting account.
4. If nameservers will change, configure A, CNAME, MX, and TXT records in the new panel beforehand; check DNSSEC status.
5. Switch the A record or nameservers to the new server.
6. Check from different networks and resolvers; clear the Google Public DNS cache if necessary.
7. Install the SSL certificate and test www and non-www addresses.
8. Send and receive a test email.
9. Keep the old server running until its logs show no traffic; then restore TTL to its previous level.

For WordPress websites, database, plugin, and permalink migration steps are handled alongside this list within the WordPress website migration service .

When should you consult a specialist for DNS problems?

If the old TTL period that answers how long a DNS change takes has expired and caches have been cleared, but the website still does not open from different networks, email does not arrive, or certificate warnings continue, specialist support saves time. These symptoms usually involve missing records or incorrect server configuration rather than a waiting period.

The transition should be systematic, particularly when the domain, hosting, and email use different companies, DNSSEC is enabled, or the old panel is no longer accessible. Domain renewal and registration options are on the domain prices page; a domain costs 1,000 TL per year, hosting 2,000 TL per year, and both together 3,000 TL, with accounts opened in the business’s name. Diagnosis is much faster when it is known which record changed, in which panel, and when.