YourWebTech documentation

DNS Propagation

Understand why DNS changes take time to propagate, what affects the speed, and how to check propagation status.

DNS Propagation

When you make a change to your DNS records — whether adding a new record, updating a value, or changing nameservers — the change does not take effect everywhere at once. This gradual rollout is called DNS propagation, and understanding how it works will help you plan changes with confidence.

What is DNS propagation?

DNS is not a single centralized database. It is a distributed, hierarchical system with thousands of DNS resolvers (also called recursive resolvers) operated by internet service providers, companies, and public services like Google (8.8.8.8) and Cloudflare (1.1.1.1).

When a resolver looks up a record for your domain, it caches the result for a period of time defined by the record's TTL (Time to Live). Until that cached entry expires, the resolver will continue to serve the old value — even if you have already updated the record at your authoritative nameserver.

Propagation is simply the process of all these resolvers around the world expiring their cached copies and fetching the new data.

What affects propagation speed?

TTL (Time to Live)

TTL is the single biggest factor. Every DNS record has a TTL value, measured in seconds, that tells resolvers how long to cache the response.

TTL valueDurationUse case
3005 minutesRecords you change frequently or are about to change
36001 hourStandard default for most records
8640024 hoursStable records that rarely change

If your current record has a TTL of 3600 (1 hour), it means resolvers that recently fetched the record may hold onto the old value for up to 1 hour.

Resolver behavior

Not all resolvers strictly follow TTL values. Some resolvers enforce minimum cache times (for example, caching for at least 5 minutes regardless of the TTL). Others may have bugs or non-standard behavior. This is uncommon but can explain why a small number of users see old data longer than expected.

Registry-level changes

Nameserver changes (as opposed to individual record changes) are processed at the registry level (.ch or .li). The registry updates its own nameserver records, which then propagate through the global DNS infrastructure. This adds an extra layer of propagation time on top of TTL-based caching.

Typical timeframes

Change typeTypical propagationWorst case
New or updated A/AAAA/CNAME recordMinutes to 1 hourUp to the old TTL value
New or updated MX/TXT recordMinutes to 1 hourUp to the old TTL value
Nameserver change15 minutes to a few hoursUp to 24-48 hours
DNSSEC DS record change15 minutes to a few hoursUp to 24-48 hours

48 hours is the commonly cited worst case for DNS propagation. While most changes take effect within an hour, you should avoid assuming instant propagation when planning migrations or launches. Always allow a buffer.

How to check propagation status

Command line tools

If you are comfortable with the terminal, dig is the most reliable way to check DNS records:

# Check A record
dig example.ch A

# Check from a specific resolver (Google)
dig @8.8.8.8 example.ch A

# Check from another resolver (Cloudflare)
dig @1.1.1.1 example.ch A

# Check nameservers
dig example.ch NS

# Check with DNSSEC validation
dig +dnssec example.ch A

By querying multiple resolvers, you can see whether the new value has reached different parts of the internet.

Online DNS checkers

If you prefer a visual interface, these web tools query dozens of resolvers worldwide and show you the results on a map:

  • dnschecker.org — Checks DNS records from multiple global locations.
  • whatsmydns.net — Similar tool with a clear geographic view.
  • MXToolbox — Especially useful for verifying MX, SPF, and DKIM records.

Your browser

Keep in mind that your browser, operating system, and local network may also cache DNS results. If you have verified that the record is correct via dig or an online checker but your browser still shows the old site:

  • Clear your browser's DNS cache (in Chrome: chrome://net-internals/#dns).
  • Flush your operating system's DNS cache (sudo dscacheutil -flushcache on macOS, ipconfig /flushdns on Windows).
  • Try a different browser or an incognito/private window.

Best practices

Lower TTL before making changes

This is the single most effective technique for fast propagation. If you plan to change a record, reduce its TTL to 300 seconds (5 minutes) at least 24 hours in advance. This ensures that by the time you make the actual change, most resolvers will have the low-TTL version cached and will refresh within 5 minutes.

One day before the change

Edit the record you plan to change and set the TTL to 300 (5 minutes). Save and wait at least 24 hours (the duration of your previous TTL) so that all resolvers pick up the shorter TTL.

Make the change

Update the record value. Since resolvers are now caching for only 5 minutes, the new value will propagate very quickly.

After the change is live

Once you have confirmed propagation is complete, you can increase the TTL back to a normal value like 3600 (1 hour) to reduce unnecessary DNS query load.

Plan changes during low-traffic periods

If you are making a change that could cause a brief interruption (like migrating to a new hosting provider), consider doing it during your lowest-traffic hours.

Avoid unnecessary changes

Every change triggers a propagation cycle. Batch related changes together rather than making multiple individual updates throughout the day.

You cannot force instant propagation. No matter what you do, some resolvers will hold onto their cached copy until the TTL expires. Lowering TTL in advance is the closest thing to instant propagation, but even then, a small number of resolvers may behave unpredictably.

Propagation and YWT hosting

If you are using YWT's built-in static hosting alongside YWT nameservers, DNS changes within YWT's own infrastructure take effect almost immediately. The propagation delay applies primarily to external resolvers caching your records. Internal requests within YWT's network will see updates right away.

For more on DNS record management, see Manage DNS Records. For specific record configurations, see Common DNS Setups.

On this page