I recently moved a domain to a new server and had to wait for the change to take effect everywhere. The process is commonly called “DNS propagation,” but that term is a bit misleading. Here is what actually happens.
DNS is not a broadcast system
When people say “DNS is propagating,” it sounds like your new record is being pushed out to servers around the world. That is not how it works.
DNS is a pull-based system. Resolvers fetch records when they need them, cache the results, and serve the cached version until it expires. When you change a DNS record, the old cached copies do not get invalidated. They simply expire over time based on the TTL (Time to Live) value.
So “DNS propagation” really means “waiting for caches to expire.”
How a DNS query works
When you type example.com into a browser, the resolution process goes through several steps.
Your device first checks its own local cache. If it has a recent answer, it uses that.
If not, it asks a recursive resolver. This is usually operated by your ISP or a public service like 1.1.1.1 or 8.8.8.8. The recursive resolver does the actual work of finding the answer.
The recursive resolver starts at the root. It asks a root name server for com., then asks the .com TLD server for example.com, and finally asks the authoritative name server for example.com for the specific record. Each answer comes with a TTL, and the resolver caches every response.
Client -> Recursive resolver -> Root NS -> TLD NS -> Authoritative NS
On the next query for the same record, the resolver serves it from cache without going through the whole chain again.
TTL controls the timing
Every DNS record has a TTL value, expressed in seconds. A TTL of 3600 means resolvers will cache that record for one hour before checking again.
When you update a record at your DNS provider, the authoritative name server starts returning the new value immediately. But resolvers that already have the old value cached will keep serving it until the TTL expires.
This is why changes are not instant. If your TTL was 86400 (24 hours), it could take up to 24 hours for all caches to expire and start returning the new value.
Checking the current state
The dig command is essential for debugging DNS. It lets you query specific servers and see exactly what they return.
Query your authoritative name server directly:
dig @ns1.yourprovider.com packetlog.org A
This bypasses all caches and shows you what the authoritative server is returning right now.
Query a public resolver to see the cached value:
dig @1.1.1.1 packetlog.org A
dig @8.8.8.8 packetlog.org A
If the authoritative server returns the new IP but the public resolver still returns the old one, you are seeing a cached answer. The ANSWER SECTION in the output includes the remaining TTL:
packetlog.org. 1742 IN A 203.0.113.10
The 1742 means this cached answer expires in 1742 seconds.
Common record types
A few record types you will work with most often:
A record. Maps a domain to an IPv4 address. This is the most common record type.
dig packetlog.org A +short
AAAA record. Maps a domain to an IPv6 address.
dig packetlog.org AAAA +short
CNAME record. An alias that points one domain to another. The resolver follows the chain to get the final IP.
dig www.packetlog.org CNAME +short
MX record. Specifies mail servers for the domain.
dig packetlog.org MX +short
TXT record. Holds arbitrary text. Used for SPF, DKIM, domain verification, and other purposes.
dig packetlog.org TXT +short
Reducing propagation time
If you know you are going to change a record, lower the TTL in advance. For example, if your current TTL is 86400 seconds, change it to 300 (5 minutes) a day before the migration. Then when you update the record, caches will expire within 5 minutes.
After the migration is complete and verified, you can raise the TTL back to a longer value. Longer TTLs are better for performance because they reduce the number of queries hitting your authoritative server.
A reasonable default TTL for most records is 3600 (1 hour). For records that rarely change, 86400 (24 hours) is fine.
Negative caching
DNS also caches negative results. If a resolver looks up a record that does not exist, it caches the “NXDOMAIN” response. The duration of this negative cache is controlled by the SOA record’s minimum TTL field.
This matters if you are adding a new record. Even if the authoritative server now has the record, resolvers that recently cached a negative result will not check again until the negative cache expires.
Troubleshooting
A few situations I have run into:
Changes seem instant from some locations but not others. This is normal. Different resolvers cached the old record at different times, so their caches expire at different times.
Changes are not visible after the TTL should have expired. Some resolvers do not strictly honor TTL. A few ISP resolvers are known to enforce a minimum cache time regardless of the TTL you set. There is not much you can do about this except wait.
Old and new values alternate. If your DNS provider uses multiple name servers and you only updated one, or if the update is still being synchronized between them, you may see inconsistent results. Most providers handle this automatically, but it can take a few minutes.
For real-time checks across many locations, whatsmydns.net shows the DNS response from resolvers around the world.
Key takeaways
DNS propagation is not a push. It is caches expiring. The TTL value on your records controls how long that takes. Lower TTL before changes, use dig to verify, and be patient. For most changes with a reasonable TTL, everything settles within an hour.