4 ms·

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 g

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.

abhinavk 2y ago
I don't know if title is edited or just pulled from URL slug. The article itself is titled: DNS "propagation" is actually caches expiring.
- inopinatus 2y ago
  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.
kortilla 2y ago
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.
- hug 2y ago
  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.
  - deleted 2y ago
    [deleted]
- inopinatus 2y ago
  I’m really repeating my own critique from when it was first published (https://news.ycombinator.com/item?id=29466513 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.
ryandv 2y ago
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. [0] https://wiki.c2.com/?VoodooChickenCoding https://wiki.c2.com/?VoodooChickenCoding

abhinavk 2y ago

I don't know if title is edited or just pulled from URL slug. The article itself is titled: DNS "propagation" is actually caches expiring.

inopinatus 2y ago
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.

kortilla 2y ago

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.

hug 2y ago
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.
- deleted 2y ago
  [deleted]
inopinatus 2y ago
I’m really repeating my own critique from when it was first published (https://news.ycombinator.com/item?id=29466513 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.

ryandv 2y ago

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. [0] https://wiki.c2.com/?VoodooChickenCoding https://wiki.c2.com/?VoodooChickenCoding