Troubleshoot DNS Propagation Issues

You have just updated your DNS records — pointed your domain to a new server, changed your MX records, or migrated to a new hosting provider — and now some users can reach the new site while others still see the old one. This inconsistency during DNS propagation is normal, but it can be stressful when you do not understand what is happening or how long it will take. This guide explains how DNS propagation works, how to monitor it in real time, and how to minimize downtime when making DNS changes.

What Is DNS Propagation?

DNS propagation is the process by which updated DNS records spread across the global network of DNS resolvers. The Domain Name System, originally defined in RFC 1035, is a distributed caching system by design. When you change a DNS record at your registrar or DNS provider, that change does not take effect everywhere simultaneously. Instead, it gradually propagates as DNS servers around the world let their cached copies of your old records expire and fetch the new ones.

The global DNS infrastructure is a distributed caching system. When a user visits your domain, their device asks a recursive resolver (usually operated by their ISP or a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1) for the IP address. That resolver checks its cache first. If it has a cached answer that has not expired, it returns the cached value without checking the authoritative DNS server. This is why different users see different results during propagation — their resolvers have cached your records at different times.

According to Cloudflare’s DNS documentation, the caching behavior is controlled by TTL (Time to Live) values set on each DNS record, which tells resolvers how long to cache the answer before checking again.

How Long Does DNS Propagation Take?

The short answer is anywhere from a few minutes to 48 hours. The actual time depends on several factors:

• TTL values — the single biggest factor. If your previous TTL was 86400 seconds (24 hours), resolvers will continue serving the cached old record for up to 24 hours after you make the change. If your TTL was 300 seconds (5 minutes), propagation will be much faster.
• ISP resolver behavior — some ISP resolvers do not strictly respect TTL values. They may cache records longer than the TTL specifies to reduce load on their infrastructure, or they may have minimum TTL floors that override your settings.
• Record type — A records and CNAME records typically propagate quickly because they are queried frequently. NS record changes take longer because they involve delegation at the registry level and may require additional propagation through the TLD nameservers.
• Geographic distance — resolvers closer to your authoritative DNS servers may update faster. Resolvers in remote geographic regions may take longer, especially if they cache aggressively.

Step 1: Check Current DNS Records

Before troubleshooting, verify what your DNS records currently say. Use the DNS Lookup tool to query your domain. The tool shows the current records as seen from the authoritative nameserver, so you can confirm your changes were actually saved at the source.

Check these records specifically:

• A record — should point to your new server’s IPv4 address
• AAAA record — should point to your new server’s IPv6 address (if applicable)
• CNAME record — if you use a CNAME instead of an A record for subdomains
• MX records — critical if you changed email providers; incorrect MX records mean lost email
• NS records — if you changed nameservers, verify the new NS records are showing at the registrar level
• TXT records — SPF, DKIM, and DMARC records for email authentication; domain verification records for services like Google Workspace

If the DNS Lookup tool shows the old values, the change has not been saved at the source. Double-check your registrar or DNS provider’s control panel before troubleshooting propagation.

Step 2: Monitor Propagation Progress

Once you have confirmed the authoritative records are correct, monitor how the change is spreading across the internet. You can check propagation from multiple angles:

• Query different public resolvers — use the DNS Lookup tool to query against Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS (208.67.222.222). If these major resolvers show your new records, most users will see the change within hours.
• Check from different locations — use the IP Lookup tool to verify that the IP your domain resolves to matches your new server. If friends or colleagues in different countries can check from their end, you get geographic diversity in your monitoring.
• Flush your local DNS cache — your own computer caches DNS results. On macOS, run sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. On Windows, run ipconfig /flushdns. On Linux, restart the systemd-resolved service.

Step 3: Identify and Fix Slow Propagation

If propagation is taking longer than expected, check these common causes:

High TTL on Old Records

If your old records had a TTL of 86400 (24 hours) or higher, resolvers that cached your records just before you made the change will hold onto the old values for up to that duration. There is nothing you can do to force these resolvers to update — you have to wait for the TTL to expire. This is why the best practice is to lower your TTL well before making changes (see “Planning for Minimal Downtime” below).

Nameserver Changes vs Record Changes

Changing your nameservers (NS records) involves an additional layer of propagation. The change must first propagate at the registry level (e.g., the .com TLD servers), and then the new nameservers must serve the correct records. According to ICANN’s nameserver documentation, NS record changes can take up to 48 hours because registries update their zone files on their own schedule.

ISP Resolver Caching

Some ISP resolvers implement minimum TTL floors — even if your TTL is set to 60 seconds, the ISP’s resolver may cache records for a minimum of 300 or 600 seconds. Users on these ISPs will experience slower propagation. There is no workaround for this on the server side; users can switch to a public resolver like Google (8.8.8.8) or Cloudflare (1.1.1.1) for faster updates.

Planning for Minimal Downtime

The best way to handle DNS propagation is to plan for it before making changes. Follow this timeline for a smooth migration:

1. 48 hours before the change — lower the TTL on the records you plan to change to 300 seconds (5 minutes). This ensures that by the time you make the actual change, most resolvers will have the low TTL cached and will refresh quickly.
2. Make the change — update the DNS records at your registrar or DNS provider. Verify the new records appear on the authoritative nameserver using the DNS Lookup tool.
3. Keep the old server running — leave your old server operational for at least 48 hours after the change. Users whose resolvers have not yet updated will still reach the old server, so it should continue serving content.
4. Monitor propagation — check multiple resolvers and geographic locations until you are confident the change has fully propagated.
5. Raise the TTL back — once propagation is complete, increase the TTL to a normal value (3600-86400 seconds). Higher TTLs reduce DNS query load and improve resolution speed for your users.

Using DNS Tools for Verification

Combine multiple tools for a complete picture during DNS changes:

• DNS Lookup — query specific record types (A, AAAA, CNAME, MX, TXT, NS) and see what the authoritative server returns.
• IP Lookup — verify that the IP your domain resolves to belongs to the correct server and hosting provider.
• Reverse DNS Lookup — confirm that the reverse DNS (PTR record) for your new server IP points back to your domain. This is especially important for email delivery.
• WHOIS Lookup — check the registrar-level nameserver delegation to confirm NS changes have taken effect at the registry.
• SSL Certificate Checker — after a server migration, verify your SSL certificate is correctly installed on the new server. A valid DNS change to a server without SSL will trigger browser security warnings.

Frequently Asked Questions