Nothing Propagates: The DNS Misnomer That Turns Migrations Into Outages

An explainer published on dev.to argues that the phrase most teams use during a migration describes a mechanism that does not exist: DNS records do not slowly travel across the internet, and there is no global synchronization event or "update internet" button ^[1][2]. That distinction is not pedantry, because it relocates cutover risk from something you wait out on the day to something you configure days before.

The model the author offers instead is four steps: you change the record, old answers expire, resolvers ask again, new answers get cached ^[3]. Propagation, in that framing, is a caching problem rather than a distribution problem ^[4]. The caches are not in one place. Browsers keep their own, operating systems keep their own, home routers and office routers and enterprise firewalls keep theirs, ISPs cache, and public resolvers such as Google DNS on 8.8.8.8 and Cloudflare DNS on 1.1.1.1 maintain large caches of their own ^[5]. According to the author, those big recursive resolvers are where most of the delay people call propagation actually originates ^[6].

The knob is TTL, which sets how long a response may remain cached before it has to be refreshed ^[7]. In the record `example.com. 3600 IN A 203.0.113.10`, the 3600 means a resolver may reuse that answer for an hour before asking again ^[8]. The article's worked case is the one that bites: a record with TTL 86400, or 24 hours, edited at 9:00 AM from 203.0.113.10 to 203.0.113.50, where many resolvers keep serving the old address until their cached copy expires and the new server may not be visible everywhere for many hours ^[9]. That is a 24x difference in worst-case exposure versus the one-hour record, purely from a number you typed at some point and forgot ^[10].

Here is the part that catches teams who do remember to lower TTL. A resolver may reuse a cached answer for the full TTL it was handed ^[7][9]. So the shorter TTL you publish is invisible to any resolver still holding the old record, and it only takes effect there once the previous, longer TTL has run out ^[11]. With an 86400 TTL in place, the lower value needs to be live at least 24 hours before cutover for every resolver to be honouring it at the moment you flip ^[12]. Lower it an hour before the migration and you have simply moved the surprise.

This also explains the reporting noise. The article notes mixed results from monitoring tools and two people seeing different versions of the same site, one via Cloudflare DNS and one via an ISP resolver, because they are not querying the same cache ^[13][14]. Disagreement between observers during a change is the expected output of the system, not evidence of a fault.

The reason not to leave everything at 60 seconds permanently sits in the same article: without caching, every lookup would walk root servers, TLD servers and authoritative nameservers for every request and every page load, which the author says would overwhelm the internet ^[15]. Caching cuts lookup time, holds down traffic across billions of daily requests, and keeps answers available when upstream systems have a bad hour ^[16].

Worth watching on the next move: what the current TTL on the records you intend to change actually is, and whether the low-TTL window opened at least that long before the cutover ^[9][12]. Until the longest TTL in play has expired, checker tools are measuring per-resolver cache state, not readiness ^[13][14].