DNS explained in plain terms: what A records and CNAMEs actually do, what TTL controls, and why a DNS change doesn’t show up everywhere at once.
Table of Contents
DNS translates a domain name into the actual server address a browser needs to connect to, and the two record types that confuse people most, A records and CNAME records, both do that same basic job in slightly different ways. Understanding the difference, along with why DNS changes take time to show up everywhere at once, clears up most of the confusion around a domain “not working yet” after a change that should have already taken effect.
A Records vs. CNAME Records
An A record points a domain name directly at an IP address, the actual numeric address of a server. When someone types your domain into a browser, the A record is what tells their computer exactly which server to connect to. A CNAME record works differently: instead of pointing to an IP address, it points to another domain name, an alias, and whatever that other domain’s own A record resolves to is where the request ultimately ends up.
A common real-world pattern: a root domain (yoursite.com) uses an A record pointing directly at your server’s IP, while www.yoursite.com uses a CNAME pointing at yoursite.com, so both addresses land in the same place without needing two separately maintained IP addresses that could drift out of sync if the server’s IP ever changes.
What TTL Actually Controls
TTL, time to live, is a number attached to every DNS record that tells other servers around the internet how long they’re allowed to cache that record before checking for an update. When a DNS resolver somewhere looks up your domain, it doesn’t ask your nameserver fresh every single time, it caches the answer for however many seconds the TTL specifies, and keeps serving that cached answer until the TTL expires. A record with a 3,600-second (one-hour) TTL means any resolver that already has it cached will keep using the old value for up to an hour after you change it, regardless of how fast your actual nameserver updates.
Why “Propagation” Is a Slightly Misleading Word
DNS doesn’t actually push changes out to the rest of the internet the way the word “propagation” implies. There’s no broadcast mechanism that notifies every resolver worldwide the moment a record changes. What actually happens is a distributed caching system running against an expiration clock: resolvers that have your old record cached keep serving it until their copy’s TTL runs out, at which point they check back with the authoritative nameserver and pick up the new value. “Propagation time” is really just the practical result of a lot of independent caches expiring on their own separate schedules, not a change actively spreading across the internet.
How Long a Change Actually Takes
For a straightforward A or CNAME record update, most visitors see the change within 5 to 15 minutes if the TTL was already set low (around 300 seconds), or within 1 to 2 hours if the TTL was left at a more common default like 3,600 seconds. The slower case is a full nameserver delegation change, switching which company’s nameservers a domain actually uses, which touches the domain’s record at the registry level and can take up to 48 hours to fully settle everywhere, since that change has to work through a different, slower layer of the DNS system than an ordinary record update.
The Practical Trick for a Faster Migration
If you know a DNS change is coming, migrating hosts, switching a domain to point at a new server, lower the TTL on the records you’re about to change roughly 48 hours in advance, dropping it from a default like 3,600 down to something like 300 seconds. That doesn’t speed up the eventual change itself, but it shrinks the maximum caching window beforehand, so once you actually make the real change, resolvers pick it up within minutes rather than potentially an hour or more, since their cached copies expire fast.
Once the new setup has been stable for a day or so, raising the TTL back up to a normal value (300 seconds means every resolver checks back with your nameserver constantly, which is fine briefly but adds unnecessary load and lookup latency as a long-term setting) is worth doing once there’s no more reason to expect further changes.
DNS Explained: What This Means Practically
If a DNS change doesn’t seem to be working somewhere, a colleague on a different network still sees the old site, a specific device or browser hasn’t caught up, that’s normal, expected caching behavior playing out on its own schedule, not evidence the change itself failed. Checking the record directly against an authoritative nameserver (rather than trusting what your own browser currently shows, since your browser’s own DNS cache is one of the things with a TTL) is the reliable way to confirm a change actually took, distinct from confirming every resolver everywhere has caught up yet.
Key Takeaways on DNS Explained
- DNS explained simply: A records point names at addresses, and CNAME records point names at other names.
- TTL controls how long changes are cached, which is why DNS explained for migrations always starts with lowering it.
- Propagation is not a wait for the internet to update; DNS explained properly shows it depends on cache lifetimes.
Related reading: How to Migrate a Website to a New Host Without Downtime and Discover the Benefits of Web Hosting with Free Domain.
Further reading: Cloudflare Learning Center: what is DNS?.