This gets reposted from time to time. The headline is trying to clickbait you into understanding DNS resolver behaviour a little better. That’s not a terrible goal but it’s unfortunately framed as something of an extended “well aktually”, hinging on a nonspecialist misunderstanding of a nontechnical (or at best, very broad) term, and the framing comes apart completely mid-argument upon accepting that yes, in fact, zone changes are push-notified so that authoritative servers can xfer the update from the master.
This latter behaviour (and perhaps, historically, the days-long turnaround time on your fax to Network Solutions or a RIR to revise delegations and glue records) is where the term really comes from, the cache-expiry part that causes longer wait times for changes to be globally effective is just kinda grandfathered in under the DNS vernacular “propagate”. And more to the good, non-technical stakeholders and project managers etc will take away the gist that the wait period is out of their direct control, without anyone having to explain the underlying mechanics.
The push is fast. Telling people to wait for propagation is incorrect. Also, this isn’t a “nonspecialist misunderstanding”. Very technical people screw this up all of the time.
> This latter behaviour is where the term really comes from, the cache-expiry part that causes longer wait times for changes to be globally effective is just kinda grandfathered in under the DNS vernacular “propagate”.
Nice job repeating the article. Everything you said is called out in the article but with useful details so people can learn to not think updating A records requires “propagation delay” to start working.
I’m really repeating my own critique from when it was first published (https://news.ycombinator.com/item?id=29466513). Despite being revised to at least mention some more of the mechanics, it’s still somewhat half-baked by omitting any discussion of zones, one of the most significant units of data in the whole system.
Moreover, the push is not always fast. There are plenty of 2ary systems in the world that will ignore the notification and only recheck serial after SOA refresh intervals, and others that will queue it for batch update later. Assuming everything works instantly is a tech sector conceit.
So what’s the one-word term for “cache expiry across multiple resolvers that handle caching differently, up to and including resolvers having more than one layer of cache due to forwarding”?
This isn’t a gotcha question: I know “propagation” isn’t a technically accurate word, but I’m sure not going to say that sentence when talking about it.
I would usually just say “after TTL expiry” to tech colleagues, but that doesn’t work for less technical conversations — saying “the change will take up to 24 hours to propagate” works better for explanations to C-level types.
If I remember correctly, it’s the original title. Both the title and text seem to have been revised. If memory serves, the original received a fair amount of energetic feedback.
Language is important. "DNS propagation" is another one of those instances of jargon or thought terminating cliches where, if DNS resolution isn't working for some reason, it can be chalked up to this poorly understood, ill-defined boogeyman of "propagation" where the mechanics of what is actually going on are simply handwaved away and hidden behind some convenient buzzword. "Try turning it off and on again," or "try again in 24 hours" as a voodoo chicken coding [0] solution to the problem.
It's the modern networking equivalent of saying "god did it," where some poorly understood phenomena is relegated to a nebulous term that isn't ever properly defined or elaborated upon. Better to dispense with such shady and fuzzy terminology and enter into a discussion of what is actually going on, which is resolver caching according to TTL fields in a DNS answer.
In light of increasing layers of opaque abstraction, encouraging people to build correct mental models of what the hell computers are actually doing is becoming ever more important.
That's exactly what I told some colleagues a few years ago when this subject came up. The information itself is propagating through the system. The fact that it relies on cache expiries and pulls is irrelevant to that; it's an implementation detail.
Yeah, it seems like someone heard 'propagation' and assumed a push-based system, then found out that was wrong, which means either they were wrong to assume propagation==push, or 'propagation' was the wrong term.
So instead of re-examining their assumption and I dunno, googling "what does propagation mean" or whatever, they've decided the problem was that ~everyone else is wrong...
For some purpose it's also possible to explicitly make a DNS request against the authoritative server (which you get from the NS record) to have an actual instantly up-to-date answer.
That's how certbot and other Let's Encrypt clients work when using the DNS verification method rather than the HTTP one (using /.well-known/…), which you need to do for wildcard certificate for example. It allows verification of the _acme-challenge TXT record instantly after the update during the certificate renewal procedure.
That's right: you can either run your DNS query against a (frequently automatically configured) resolver that will pursue the query on your behalf up to the authoritative nameserver declared in the NS record and have that resolver cache the authoritative or "real" response returned by that nameserver (hopefully) according to the TTL specified in the answer, potentially receiving stale answers on subsequent requeries if the authoritative record changes before the resolver's cache expires; or directly query the authoritative nameserver yourself to get the most up-to-date answer without having to wait for the resolver's caches to expire.
In the former case you may get a stale answer, up to the (possibly nonconformant) caching behaviour of the resolver and how long the cached value has left to live; in the latter case you are probably assured to receive the most up-to-date answer for that record.
The recursive resolver you describe would adhere to the same TTL as would do any reasonable public resolver. The difference in cache behaviour, if any, only depends on if the resolver already has a cached record that's still valid or doesn't have it. That it won't have it just happens to be more likely as the amount of requests your resolver received is smaller as the case if you are it's sole user. It's possible to force the behaviour you described by using specialised tools that are meant to be used for analysis like binds dig utility with its trace flag. It can bypass any resolver by querying up from the root servers to the designated label without any caches being involved. You still only will know that other resolvers will receive the desired answer eventually. Only safe bet is to assume it will take the TTL until every will receive the updated record.
That's correct, "directly query the authoritative nameserver yourself" is precisely what dig +trace does.
> You still only will know that other resolvers will receive the desired answer eventually.
That's also correct. DNS is an eventually consistent system where if you stop updating the authoritative records, all resolvers will eventually converge to the latest answer once their cached records expire (presuming that they actually respect the cached records' TTLs as expected).
> Instead, very rudely, some resolvers will ignore your TTL and just cache your record for as long as you feel like! Like 24 hours!
Kinda surprised to hear about this one. Wouldn't this instantly break DynDNS domains that rely on short TTLs so they can keep the server's IP address in sync?
This is more common than you might think. I have encountered cheap home routers that have dumb dns proxy caches on them that simply cache everything for a fixed time period. I heard of one that simply flushed its cache at the same time every hour.
You find out all sorts of bad DNS behavior when you run anything CDN related.
It’s way less of a problem now than it was 20 years ago (at least in the Western countries I have services in my career) but it has traditionally also been an issue for a hard cutover of services, especially for SMB and even small enterprise businesses doing things like MX cutovers.
For hard cutovers it might be a viable strategy to forward or redurect traffic inbetween changes. That is, either let the old destination forward to the new, or vice versa, then update the records to the new destination, or have an intermediary forwarding destination where you can change the destination address on an an instant and once settled move the record to that.
24h seems overly excessive but some resolvers may refuse to adhere to arbitrary low TTL and chose to answer with stale records from cache for as long as they deem necessary. 24h certainly would make many issues with that strategy very apparent.
historically, dns authoritative secondaries would only axfr every so often, so a query to an authoritative secondary server would still get you old records until the next axfr, possibly many hours or a day later. nowadays usually some form of push notification protocol like https://www.rfc-editor.org/rfc/rfc1996 usually makes this effectively instant, but that isn't always reliable. the pre-dns way of doing this was even slower (ftp a new hosts file from the nic). so sometimes, and for most of the history of the internet always, new hostnames do propagate, over time, gradually
the advice to wait for propagation dates from the time before notify
This latter behaviour (and perhaps, historically, the days-long turnaround time on your fax to Network Solutions or a RIR to revise delegations and glue records) is where the term really comes from, the cache-expiry part that causes longer wait times for changes to be globally effective is just kinda grandfathered in under the DNS vernacular “propagate”. And more to the good, non-technical stakeholders and project managers etc will take away the gist that the wait period is out of their direct control, without anyone having to explain the underlying mechanics.