Overview
DNS propagation is the time it takes for DNS record changes to spread across the global network of DNS servers after you make an update. When you move a domain to Host & Tech, change your nameservers, or update an A record, that change doesn’t go live everywhere at once. It ripples outward, and how fast that happens depends on a setting called TTL (Time to Live).
Most users run into this after migrating a site or launching a new one. They update the nameservers, wait a few minutes, and then wonder why the site is still pointing at the old host. The frustrating reality is that you can’t force the entire internet to update immediately — but you can understand what’s happening and minimize the wait if you plan ahead.
This article explains how DNS propagation works, what TTL actually controls, how to check propagation status, and what to do when something seems stuck.
Prerequisites
- Access to your domain registrar account (where you manage nameservers) or your DNS zone editor in cPanel/WHM/Plesk
- The new DNS records or nameservers you plan to use
- Basic familiarity with DNS record types (A, CNAME, MX) is helpful but not required
- Optional: a terminal/command prompt for manual DNS lookups
How DNS Propagation Actually Works
When someone types your domain into a browser, their device asks a DNS resolver (usually run by their ISP or a public service like Google’s 8.8.8.8) to look up the IP address for that domain. That resolver checks its local cache first. If it has a recent answer cached, it uses that — no matter what you changed at the source.
That cached answer stays valid until the TTL expires. TTL is a number (in seconds) attached to every DNS record. A TTL of 3600 means resolvers can cache that record for one hour before they have to re-check. A TTL of 86400 means 24 hours.
So when people say “DNS propagation takes 24–48 hours,” what they really mean is: every resolver on the planet has to wait for its cached copy of your old record to expire before it fetches the new one. Resolvers in different countries, on different networks, cached your record at different times — so they expire at different times. That’s why you might see your new site immediately on your phone but your colleague in another city still sees the old one.
📝 Note: DNS propagation and nameserver propagation aren’t exactly the same thing. Changing individual records (like an A record) within an existing zone is usually faster than changing your domain’s nameservers entirely, because nameserver changes also require the TLD registry (e.g. .com, .ca) to update its delegation records.
Step-by-Step: Managing DNS Propagation
Step 1 — Lower Your TTL Before You Make Changes
This is the most useful thing you can do, and most people skip it. If you know you’re migrating a site or changing nameservers in the next few days, lower your TTL to 300 (5 minutes) at least 24–48 hours before you make the actual change. That way, when you do update the record, resolvers only need to wait 5 minutes to pick it up instead of 24 hours.
In cPanel, go to Domains > Zone Editor, find your A record or relevant record, click Edit, and change the TTL field to 300. In Plesk, go to Websites & Domains > DNS Settings, click the record, and update the TTL there.
⚠ Warning: Don’t forget to raise the TTL back to something reasonable (like 3600 or 14400) after migration is complete. A permanently low TTL means every DNS lookup has to hit the authoritative server more often, which adds unnecessary load and slightly increases resolution time for visitors.
Step 2 — Make Your DNS Change
Update your record in whichever system controls your zone. If Host & Tech is managing your DNS (which is the case with our Shared Hosting plans and most managed setups), you’ll do this through cPanel’s Zone Editor or via WHM for resellers.
If you’re only changing nameservers (full DNS migration), log into your registrar and point the nameservers to the ones provided in your Host & Tech welcome email. They’ll look something like:
ns1.hostandtech.com
ns2.hostandtech.com📝 Note: Nameserver changes are processed by the domain registry, not just your registrar. ICANN requires registries to process these updates within 24 hours, but in practice most TLDs (including .com and .ca) push the change out within a few hours.
Step 3 — Check Propagation Status
Don’t just keep refreshing your browser — your local DNS cache will keep serving the old result even after most of the world has moved on. Use these tools and commands instead:
Online tools:
- dnschecker.org — shows your record’s current value from ~30 locations worldwide
- whatsmydns.net — good for a quick global snapshot
From the command line (Linux/macOS):
# Query a specific public resolver to bypass your local cache
dig @8.8.8.8 yourdomain.com A
# Check what TTL is currently being served
dig yourdomain.com A +ttlunits
# Check nameserver delegation
dig yourdomain.com NSFrom Windows (Command Prompt or PowerShell):
nslookup yourdomain.com 8.8.8.8If dig @8.8.8.8 returns the correct new IP but your browser still shows the old site, the problem is your local DNS cache — not propagation.
Step 4 — Flush Your Local DNS Cache
If the global resolvers have your new record but your machine still doesn’t, flush the local cache:
macOS (Ventura/Sonoma/Sequoia):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderWindows 10/11:
ipconfig /flushdnsLinux (systemd-resolved):
sudo resolvectl flush-cachesAfter flushing, close and reopen your browser. Browsers also maintain their own internal DNS cache. In Chrome, you can clear it at chrome://net-internals/#dns — click Clear host cache.
Common Issues & Troubleshooting
Site still shows old host after 48 hours
First, verify the change actually saved at the authoritative source. Run:
dig @ns1.hostandtech.com yourdomain.com AIf this returns the wrong IP, the record wasn’t saved correctly on the authoritative nameserver — propagation has nothing to do with it. Log back into your zone editor and confirm the A record is pointing to the right IP. If the authoritative answer is correct but resolvers worldwide still show the old value after 48 hours, check whether the old record had an unusually high TTL (like 86400 or higher). Some registrars default to 48-hour TTLs.
Different results depending on which network you’re on
This is normal during propagation, but if it persists past 72 hours, it usually means one ISP’s resolver is being stubborn. Some ISPs override TTL values and cache records longer than they should. There’s not much you can do about it directly — but you can tell affected users to switch their device’s DNS to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) temporarily, which will bypass the ISP’s resolver entirely.
Email stopped working after changing nameservers
This happens when MX records weren’t recreated in the new DNS zone before the nameserver change went live. When you migrate to Host & Tech nameservers, the new zone needs to have all your existing records — A, MX, CNAME, TXT — before you flip the nameservers. Check your MX records with:
dig yourdomain.com MXIf they’re missing or wrong, add them in cPanel’s Zone Editor immediately. Mail will resume once the correct MX records propagate, but any mail sent during the gap may have bounced.
Propagation checker shows the new IP but HTTPS returns a certificate error
DNS is working fine — this is a TLS/SSL issue. The SSL certificate was likely issued for the old server or hasn’t been provisioned on the new one yet. On Host & Tech shared hosting and managed WordPress plans, AutoSSL runs automatically via cPanel, but it needs the domain to be resolving to the server first. Wait for propagation to complete fully, then trigger AutoSSL manually: in WHM go to SSL/TLS > Manage AutoSSL and run it for the account.
TTL shows 0 or a very low number unexpectedly
A TTL of 0 in a dig response usually means you’re seeing a cached answer that’s about to expire — it’s the remaining cache lifetime, not the record’s actual TTL. Run the query against the authoritative nameserver directly (as shown in Step 3) to see the real configured TTL value.
FAQ
Frequently Asked Questions
How long does DNS propagation take?
Most DNS changes propagate within 1–4 hours for the majority of users worldwide. The 24–48 hour figure is the worst-case ceiling, not the average. If you lowered your TTL to 300 seconds before making the change, most resolvers will pick up the new record within 5–10 minutes.
Why does my site load correctly on my phone but not my computer?
Your phone and computer are likely using different DNS resolvers, which cached your old record at different times. Your computer’s local DNS cache may also be holding onto the old result. Flush your DNS cache using the commands in Step 4 above and clear your browser’s internal DNS cache as well.
Can I speed up DNS propagation?
Yes, but only if you act before making changes. Lower your record’s TTL to 300 seconds at least 24 hours in advance — this is the single most effective thing you can do. Once you’ve already made the change with a high TTL, there’s no way to force remote resolvers to refresh early. You just have to wait.
Does DNS propagation affect email as well as the website?
Yes. Any DNS record type can take time to propagate, including MX records that control email routing. If you’re migrating hosting and need email to keep working without interruption, make sure your MX records are correctly configured in the new zone before you switch nameservers.
What's the difference between TTL and DNS propagation?
TTL is a setting on a DNS record that tells resolvers how long to cache it. DNS propagation is the real-world process of those caches expiring and resolvers fetching the updated record. TTL directly controls how long propagation takes — a shorter TTL means faster propagation, a longer one means slower.