Yes, thank you! This idea of "propagation" is a pet-peeve of mine. It's a widespread misconception and hopefully more people will see this post since understanding how DNS works is important foundational knowledge.
This is a type of common HN post. Where the person posting is going over well known knowledge. Others that are similar are "I wrote a compiler." and "I made a emulator." Usually they are subsets of the problem space and sometimes quite often don't demonstrate any expert knowledge of the subject. Perfectly fine personal projects, but hard to understand why they're worth blogging about.
And FWIW, DNS absolutely propagates in a push fashion in circumstances where people are running large DNS installations with multiple authoritative servers.
On this, though: "new DNS records are actually available instantly"
Depends on who is serving your DNS records and what sort of interface they give you to make updates. There are many where your update makes an update in a separate database and the actual zone file updates are batched every X minutes.
And on this: In the 90s, maybe DNS records really did take multiple hours to get “propagated” and pushed out, and so it was more accurate to use the term “propagation” to describe why you needed to wait?
Things aren't technically substantially different than they used to be. People probably used longer TTL values, but that would be by choice.
In the 90s Many questionable ISPs would ignore TTL values and thus you would be left with a situation where even with a reduced TTL for a maintenance window, you would still be stuck waiting for DNS caches to expire remotely.
Sure some places would take a little time for zone transfers within their internal NS servers, but primarily your delay was always the remote cache and TTL adherence
You need to wait for caches to expire, such that your new entry can propagate. But you are still technically correct, which we all know is the best kind of correct.
Yes, my conception of "propagate" is "the data gets there one way or another", and by using "propagate" the specifics of whether or not it's a push or pull model is unimportant. Good to know not everyone sees it that way though; that'll help when writing for others
It probably doesn't, but I think "to propagate" is easily deemed an active engagement as opposed to a passive one. eg. while one can propagate an idea by doing nothing but waiting for people to come to them, I'd expect most people to assume "let's propagate this new idea" to mean a more active role in disseminating it — even if not quite directly reaching out to people.
Would you assume some particular method of transfer was in play if someone said “the idea propagated out from the capital city”? To me it could be any number of ways, but in the end it spread out. It sounds like some people take this usage to mean the only possibility is that people from the capital city must have been going out and evangelizing it actively, not that people were visiting the capital and hearing it or something.
I've always read it as a purposeful lack of describing effect. A word used when you don't want to address the "how" question, just that the spread happened.
Exactly, I think that’s a better way to describe it. “Propagation occurred from inside out, rather than outside in” is talking about a state changing over time, but saying nothing about how that happened.
I was actually careful not to equate "active" with "directly reaching out to people," but taking any active means of furthering the spread of the idea.
And, yes, I'd personally consider word-of-mouth to be largely push-based. But I concede it could just as well be people asking (perhaps too many) questions.
"3. (with reference to motion, light, sound, etc.) transmit or be transmitted in a particular direction or through a medium"
This is the third definition the search engine I use returns for the term, and by it you are indeed correct. The direction, and method are unspecified.
In other words, the term "propagation" is quite likely not the source of people's confusion that the original blog post thinks it is. It's great that they investigated for themselves and figured out what's going on, and wrote up an explanation of it. That's useful, but note the section of the post 'okay, DNS records actually do “propagate”.'. By taking issue with the term "propagate" they've just muddied the waters yet again.
Sadly, the author hasn’t even realised their own flawed assumption, despite contributing plenty of words sledging those of others. The hint, from the text, is how you can practically hear the agitated airquotes around propagate.
What's more, the DNS does conventionally distribute zone updates via notification from master to replica. Despite its relevancy this mechanism is not discussed; in fact the word zone does not appear at all in this article, which is hoist with its own petard in presenting a half-baked model of the DNS.
That’s why I always resist the desire to lookup (touch/ping/visit) names when changing ips or reissuing certificates by “get on any linux copy to your windows” method. Once it is cached, you’re doomed to go make some coffee. Only test-visit at the end — and your subnet instantly “updates” on it without delays.
There’s nothing wrong with your workflow but personally I prefer checking because beforehand so I have that additional assurance that I’ve made the right change. Baring in mind that it’s easy to flush the DNS cache on most operating systems and dig makes checking resolvers simple.
> When people say “we’re waiting for DNS to propagate”, what they actually mean is “we’re waiting for cached records to expire”.
And when people say "the new data needs to propagate" they usually mean "all the old versions of the data need to be replaced with the updated version". Which is exactly the what "waiting for cached records to expire" means. I don't really see the point of this article, besides to express some sort of overly pedantic characterization of push vs pull event propagation techniques. Did anyone really think that every time someone makes a DNS update it is broadcasted to every DNS resolver on the internet?
Edit in response to general feedback: The article should be titled "DNS doesn't push". The DNS consistency process satisfies any reasonable definition of "propagation" so claiming "DNS doesn't propagate" is confusing at best and misleading clickbait at worst.
I have heard dozens of people describe DNS this way, yes, like it's a push behaviour. I don't know how much it matters but I think making it clearer is good.
DNS servers push to other authoritative resolvers. There are all kinds of topologies for zone transfers.
It's not what a user thinks of, but in terms of I updated a record and have to wait for it to be "everywhere" it's entirely part of the change latency to the end user and outside the scope of caching and TTLs being honored.
If I write a book and publish it, am I not propagating the ideas written on it? I still require readers to go online or to a bookshop and purchase my book, then read it. Once they do, the information has propagated to them. If someone explicitly asks them about the book and gets a good explanation, my ideas propagate further.
In the case of DNS, the information does emanate from the upstream server, but only upon request, like the ideas in the book.
I don't think anyone would phrase it that way, no. "Propaganda" generally involves things like mass leaflet drops, messages blasted out of public address systems, that sort of thing.
> Did anyone really think that every time someone makes a DNS update it is broadcasted to every DNS resolver on the internet?
Absolutely. All of these, especially to an average person, imply the data takes a while to be pushed out "across the internet".
GoDaddy [1]: "but it can take up to 48 hours for everything to propagate across the Internet"
Namecheap [2]: "it is a period of time ISP (Internet service provider) nodes across the world take to update their caches with the new DNS information of your domain."
AWS [3]: "DNS propagation is the amount of time that it takes for DNS changes to be updated across the internet"
I don't really see the point of your comment, besides to express some sort of overly pedantic characterization of push vs pull event propagation techniques.
I responded because I felt the “Did anyone really think” comment was arrogant and dismissive. I provided examples where a layperson could easily reach that conclusion.
They do imply a push. A pull would mean that things mightn't spread across the internet in the event no-one requested them. Those statements do imply that things just get spread across the internet automatically.
"By 48 hours, the news will have spread around the globe." (a more natural phrasing than propagate in the context of news, but I think pretty identical in implication) does not imply a push model, I just completely disagree with you.
It doesn't matter how pedantic the correction seems from the perspective of those of us who understand DNS, because we aren't the target audience of the correction. Tightening up the terminology is a small price to pay for being helpful.
> Did anyone really think that every time someone makes a DNS update it is broadcasted to every DNS resolver on the internet?
This behavior might indeed apply to many services with a global DNS footprint (multi-continent redundant authoritative DNS servers), but that's even more pedantic and, in the end, we just want the DNS update be realized by all users in a respectable amount of time.
> Did anyone really think that every time someone makes a DNS update it is broadcasted to every DNS resolver on the internet?
Yes. Absolutely. Well, not every DNS resolver on the internet, but at least every one that has it cached.
I think it's partly because push-propagation does happen at very limited parts of the picture, when updating master replicas.
It's not pedantic, because there is an observable, human-significant behavioral difference: if you update a DNS record and then test it before the TTL has expired, there's a good chance you'll already see the update. And a good chance that then testing immediately from somewhere else, you won't see the update.
With the mental push model of DNS propagation, you have to reach for weird explanations for this behavior -- "oh, I guess something is still working through its list of servers to push this to" or something equally dubious. With the stale cache entry mental model, it's just: "it wasn't in the cache".
I mean, considering what the source is (jvns.ca is a blog that is fairly well known around these parts to talk about technical content), and the usage of quotes in the title, one should hopefully infer that there's going to be some level of pedantry in this post.
I share the sentiment that for the average joe, a push vs pull distinction is fairly irrelevant, and that for the more networking-savvy, this is all more or less old news. This feels like the type of post that is targeted at the 10,000[0] people in between who may not realize that their mental model of DNS propagation may not be correct (and they'd appreciate being nudged about it)
"Propagate" describes high level system behavior, and is thus correct regardless of the underlying mechanics being push or pull. Another thing you have/had to wait for is zone transfers, from "primary" authoritative servers to "secondary" authoritative servers. Today this has been mostly alleviated with NOTIFY or synchronization functionality outside of the original BIND (eg SQL backend of PowerDNS, or copying zone files across servers like every other config), modulo your specific infrastructure of course.
IME when you make a change to your name servers at your registrar, you see that change updated in the TLD's servers pretty quickly (a few minutes). So we're basically down to whatever time your own infrastructure takes to update, plus TTL timeouts of recursive resolvers (and cached failures), as the post covers. You can follow such progress by using dig/nslookup on the authoritative servers directly (your own and/or the TLD's, depending what's updating).
(Originally in response to the now-dead comment asking what propagate means.)
"Propagate" means "spread out from a seed location to other locations."
Which is a valid description of the effect of what happens with DNS, assuming the changes are also being requested by end clients. It's just that we silly hoomanz connect together an effect (propagation) with the most obvious mechanism (it gets pushed from the start location to other locations), to the point that we mentally equate the term 'propagation' with that mechanism.
Come to think of it, even in the plant world the term "propagation" is kind of backwards. Something that propagates from cuttings relies on an external force to rip off a chunk and deposit it elsewhere. The plant doesn't throw its own severed appendage (well, except in some limited cases.) Even for seeds, dandelions rely on wind to pull the pretty fluffy bits off and deposit them elsewhere. It's just that the false equivalence works better in the plant world because it's new stuff and—as with DNS—new stuff doesn't have the problematic state of old stale cache entries lying around. And that's where the flawed mental model results in a difference in observed behavior.
(Yeah, Evans's explanation was better. And she pointed me to the 8.8.8.8 force flush page, which is awesome.)
Yeah, that's the sort of thing I was thinking of. I grew up around a lot of Scotch Broom, which fling their seeds rather violently when disturbed.
But I removed the example because at that point I was talking about parts of plants rather than seeds. I don't actually know of an example of a plant hurling away a non-seed part of itself for budding, though I'd be surprised if it doesn't exist.
You know, I think this also relies on wind (but not completely, as you say.. an animal could set it off, and maybe a seed might stick to its fur!).
But can you imagine during a strong windstorm, how much farther these seeds would go? Especially fall windstorms. The wind is doing 20mph, and then these seeds go flying up in the air...
The one in the youtube video yeah, but the first link describes other plants with other triggers - one of which seems to just go on its own once mature.
In life the effect is to reproduce genes. The mechanism could be anything. To release seeds at a particular time. Or be tasty to humans. Or have pretend eyes that deter predators. The effect is the same. A pet cat is not getting propogated by humans. The genes for cuteness are using humans as a mechanism to spread themselves.
Heck, even ICANN use the term propagation in their functional requirements for DNS, so does IETF in their RFC for DNS.
People are just being too pedantic and nerdy of the use of the term. Of course one word cannot explain the technical aspect of how it actually works, that's why we use the term. It describes the general principle of how it works.
Came here to say exactly this, the argument seems more that the label tells you little about the process besides its observable behaviour, which is generally how it goes.
I think the article is unreasonable pedantic. But in a legal context, I would support it, because that is basically the justification for DNS censorhsip, which sadly has become more popular again.
People who ran DNS servers in the 90s also ran the routers, where propagation is a function of routing protocols with announcements and broadcasts. They also may have run the newsfroup feeds, where articles would spread out through other feeds. By people, I mean me, anyway.
Article is blaming a misconception on the terminology. Terminology is correct. DNS actually uses both push and pull for different parts of propagation, in fact.
I tried using the 8.8.8.8 one for one domain, but sending emails from Gmail to that domain failed for hours, so it's not perfect. One would at least think that Gmail uses 8.8.8.8 for DNS.
Domains themselves don't use DNS servers in the same way your network connection needs DNS to work right. Did you try using 8.8.8.8 for your domain's nameservers? Because that's a misconfiguration - your domain's nameservers need to be configured to be authoritative for your domain - which Google's HonestDNS is not going to claim to be. (Even if you're using GCP.)
I think he meant he used the Flush Cache functionality of 8.8.8.8 but emails still failed on Gmail until their cache was invalidated (so Gmail probably is not using 8.8.8.8, or the flush cache doesn't actually works as intended).
caches are hierachical. Even your local machine most of the time now with recent OS releases will cache records, then your home router or some other DNS server on your network will often cache things before then referring to your ISPs or Googles DNS server.
Invalidating the cache at one doesn't invalidate the cache downstream of them if they already looked the record up recently. But it does mean that anyone who hadn't looked up the record will get the correct result straight away.
Was it failing at GMail before you flushed at 8.8.8.8? Because then you would have to wait while GMail's own cache expired, assuming they even use the public 8.8.8.8 service.
And it's not like they need to hold on to any state to work. If you had access you could purge everything and have them start fresh from the root servers, and it would work fine. (As long as the load spike doesn't make it decide to do something dumb, of course.)
It's like correcting someone for saying lightning struck something on the ground, even though the current starts on the ground and "strikes"up at the sky. Even though the ground is "pushing" the lighting bolt up to the sky, it's the conditions of the sky that led to the ground push the current upwards.
"Current" is an abstraction, that to physicists is defined as the direction of positive charges flowing. Since most currents are actually due to moving electrons, the direction of current by convention is the opposite the way electrons move in a circuit. (Blame Ben Franklin for guessing the wrong convention, I think.)
Actual moving positive charges (e.g. ions in solution) do move in the direction of "current".
it's good to know how things work under the hood. A lot of people use handwavy language to describe basic levels of technical abstraction when it would do everybody much more good to explain the concepts in the simplest way - according to how it actually works.
Why do slow-mo lightning shots clearly show the opposite then? Unless you're referring to "conventional current", which is about as pedantic as you can get given that that's an obsolete and incorrect school of thought based around flow of positive charges before electrons were discovered.
No, it's not. Understanding how DNS changes work is actually necessary when debugging DNS issues or doing work around an infrastructure that uses DNS. Thinking the "propagation model" is correct when working on these systems will make you ineffective at your job, and possibly break things.
For the average non-technical user, it's fine to use the "propagation" explanation. It's easy to understand, and it does describe the result the user sees, even if it gets the mechanism wrong. But the propagation explanation has become so widespread and ingrained that technical people who need to know the correct explanation often don't, and don't even realize that they've had the wrong information for years.
The author of the article couldn't even come up with a solution or better term to use. The term propagation is used by ICANN in their functional requirements and used by the IETF in their DNS RFC. Even CloudFlare uses the term.
A single word isn't going to tell you exactly how something so technical works, but it is the most correct term to use to describe what is occurring.
If you aren't aware that DNS propagation is actually about waiting for cached DNS records to expire then maybe you shouldn't be the one debugging DNS issues in the first place?
I think propagation it's highly descriptive. You make a change and then you wait for various DNS servers to acknowledge that change (once cached records expire).
I feel like in situations where you say 'propagate' you understand it's wrong but it's going to translate to other people well. Those other people also understand it's an impossible question to truly answer. If DNS isn't even cached to begin with it's just solved. So the whole DNS propagation is highly contextual.
Worse yet, now all DNS software is the same. Some caching dns servers still do the query every time. It's just that you answer with cache so it's fast. Some DNS servers will fail once and then near immediately be fixed.
Since it's such a complicated subject. It's better to generalize and simplify as 'propagate'.
Except for when it is.... If you increment the serial number of a zonefile on your authoritative ns1 and reload the zone, it will push it to any slaves that are configured and set as authoritative for the zone. Very standard IXFR config.
If we are referring to third parties' caching recursive resolvers updating a zone, then yes, it absolutely is pull not push.
To be fair, your ns secondaries usually does pull the zone (axfr) or zone changes (ixfr) from the primary - the zone reload just sends a notify to trigger it.
Article specifically addresses this, and "pull, not push" is specifically talking about clients querying resolvers, not zone transfers. No need for the pedantry this time.
This begs the question though: Did her colleague truly believe that a client keeps a record of all DNS records for the entire internet? This is the unspoken result of a belief that DNS is push vs pull.
Otherwise, this is just a simple misunderstanding about which systems are clients in the relationship, which I suppose is less fun to write a blog about.
> it will push it to any slaves that are configured
But "it" here doesn't include every DNS server, right? Because, e.g., djbdns definitely doesn't do any pushing when you rebuild the database. And PowerDNS has "native replication" mode where there's no pushing done by the server on changes.
I wonder if DNS caching is really worth doing these days anywhere other than client systems. If my browser/OS caches a DNS entry, is it worthwhile anyone else caching it?
Probably. If you are a resolver and each client caches the DNS for 5 minutes and you have 300 people constantly accessing a certain domain, you have to make 1 request upstream every second. However, if you cache it for 5 minutes yourself, you only have to make 1 request every 5 minutes. Actually, even if you had a single client, it may still be the case that their caching preferences differ from yours, assuming that either of you are willing to disregard the actual record TTL.
> When people say “we’re waiting for DNS to propagate”, what they actually mean is “we’re waiting for cached records to expire”.
This shows a fundamental misunderstanding. It has nothing to do with push or pull. It also has nothing to do with when the information was propagated - before the request had been made or afterwards.
When you attempt to resolve a website's IP address from a URL, that is almost never done by sending a request to the authoritative server that owns that particular bit of information but to a caching resolver that requires the data gets propagated from the other server.
That's mostly correct, but a new record isn't always propagated down the chain when there is a cache miss. Other resolvers may not yet have the updated record.
Great article in terms of educating people about DNS. I agree with most of the comments here that 'propagate' is still accurate in that it describes the behavior of the system though. Maybe im biased though because I sustain a project that markets itself as visualizing DNS propagation...
Shameless plug: To view your DNS 'propagation' (or whatever you want to call it) in 'realtime' check out dug!
163 comments
[ 3.0 ms ] story [ 201 ms ] threadAnd FWIW, DNS absolutely propagates in a push fashion in circumstances where people are running large DNS installations with multiple authoritative servers.
On this, though: "new DNS records are actually available instantly"
Depends on who is serving your DNS records and what sort of interface they give you to make updates. There are many where your update makes an update in a separate database and the actual zone file updates are batched every X minutes.
And on this: In the 90s, maybe DNS records really did take multiple hours to get “propagated” and pushed out, and so it was more accurate to use the term “propagation” to describe why you needed to wait?
Things aren't technically substantially different than they used to be. People probably used longer TTL values, but that would be by choice.
Sure some places would take a little time for zone transfers within their internal NS servers, but primarily your delay was always the remote cache and TTL adherence
This post brought to you by mavengang.
I'd be that person. "Propagate" strongly implies a push model to me; parent-to-child reproduction like an organism.
And, yes, I'd personally consider word-of-mouth to be largely push-based. But I concede it could just as well be people asking (perhaps too many) questions.
This is the third definition the search engine I use returns for the term, and by it you are indeed correct. The direction, and method are unspecified.
In other words, the term "propagation" is quite likely not the source of people's confusion that the original blog post thinks it is. It's great that they investigated for themselves and figured out what's going on, and wrote up an explanation of it. That's useful, but note the section of the post 'okay, DNS records actually do “propagate”.'. By taking issue with the term "propagate" they've just muddied the waters yet again.
Sadly, the author hasn’t even realised their own flawed assumption, despite contributing plenty of words sledging those of others. The hint, from the text, is how you can practically hear the agitated airquotes around propagate.
What's more, the DNS does conventionally distribute zone updates via notification from master to replica. Despite its relevancy this mechanism is not discussed; in fact the word zone does not appear at all in this article, which is hoist with its own petard in presenting a half-baked model of the DNS.
Also googled this out of curiosity: https://www.a2hosting.com/kb/getting-started-guide/internet-... (How to clear the DNS cache on your computer: win, osx, linux)
And when people say "the new data needs to propagate" they usually mean "all the old versions of the data need to be replaced with the updated version". Which is exactly the what "waiting for cached records to expire" means. I don't really see the point of this article, besides to express some sort of overly pedantic characterization of push vs pull event propagation techniques. Did anyone really think that every time someone makes a DNS update it is broadcasted to every DNS resolver on the internet?
Edit in response to general feedback: The article should be titled "DNS doesn't push". The DNS consistency process satisfies any reasonable definition of "propagation" so claiming "DNS doesn't propagate" is confusing at best and misleading clickbait at worst.
It's not what a user thinks of, but in terms of I updated a record and have to wait for it to be "everywhere" it's entirely part of the change latency to the end user and outside the scope of caching and TTLs being honored.
In the case of DNS, the information does emanate from the upstream server, but only upon request, like the ideas in the book.
I don't think anyone would phrase it that way, no. "Propaganda" generally involves things like mass leaflet drops, messages blasted out of public address systems, that sort of thing.
Absolutely. All of these, especially to an average person, imply the data takes a while to be pushed out "across the internet".
GoDaddy [1]: "but it can take up to 48 hours for everything to propagate across the Internet"
Namecheap [2]: "it is a period of time ISP (Internet service provider) nodes across the world take to update their caches with the new DNS information of your domain."
AWS [3]: "DNS propagation is the amount of time that it takes for DNS changes to be updated across the internet"
[1] https://www.godaddy.com/help/what-factors-affect-dns-propaga...
[2] https://www.namecheap.com/support/knowledgebase/article.aspx...
[3] https://aws.amazon.com/premiumsupport/knowledge-center/route...
I responded because I felt the “Did anyone really think” comment was arrogant and dismissive. I provided examples where a layperson could easily reach that conclusion.
This behavior might indeed apply to many services with a global DNS footprint (multi-continent redundant authoritative DNS servers), but that's even more pedantic and, in the end, we just want the DNS update be realized by all users in a respectable amount of time.
Yes. Absolutely. Well, not every DNS resolver on the internet, but at least every one that has it cached.
I think it's partly because push-propagation does happen at very limited parts of the picture, when updating master replicas.
It's not pedantic, because there is an observable, human-significant behavioral difference: if you update a DNS record and then test it before the TTL has expired, there's a good chance you'll already see the update. And a good chance that then testing immediately from somewhere else, you won't see the update.
With the mental push model of DNS propagation, you have to reach for weird explanations for this behavior -- "oh, I guess something is still working through its list of servers to push this to" or something equally dubious. With the stale cache entry mental model, it's just: "it wasn't in the cache".
I mean, considering what the source is (jvns.ca is a blog that is fairly well known around these parts to talk about technical content), and the usage of quotes in the title, one should hopefully infer that there's going to be some level of pedantry in this post.
I share the sentiment that for the average joe, a push vs pull distinction is fairly irrelevant, and that for the more networking-savvy, this is all more or less old news. This feels like the type of post that is targeted at the 10,000[0] people in between who may not realize that their mental model of DNS propagation may not be correct (and they'd appreciate being nudged about it)
[0] https://xkcd.com/1053/
IME when you make a change to your name servers at your registrar, you see that change updated in the TLD's servers pretty quickly (a few minutes). So we're basically down to whatever time your own infrastructure takes to update, plus TTL timeouts of recursive resolvers (and cached failures), as the post covers. You can follow such progress by using dig/nslookup on the authoritative servers directly (your own and/or the TLD's, depending what's updating).
"Propagate" means "spread out from a seed location to other locations."
Which is a valid description of the effect of what happens with DNS, assuming the changes are also being requested by end clients. It's just that we silly hoomanz connect together an effect (propagation) with the most obvious mechanism (it gets pushed from the start location to other locations), to the point that we mentally equate the term 'propagation' with that mechanism.
Come to think of it, even in the plant world the term "propagation" is kind of backwards. Something that propagates from cuttings relies on an external force to rip off a chunk and deposit it elsewhere. The plant doesn't throw its own severed appendage (well, except in some limited cases.) Even for seeds, dandelions rely on wind to pull the pretty fluffy bits off and deposit them elsewhere. It's just that the false equivalence works better in the plant world because it's new stuff and—as with DNS—new stuff doesn't have the problematic state of old stale cache entries lying around. And that's where the flawed mental model results in a difference in observed behavior.
(Yeah, Evans's explanation was better. And she pointed me to the 8.8.8.8 force flush page, which is awesome.)
> once it is mature and dry, detaches from its root or stem and rolls due to the force of the wind.
> Apart from its primary vascular system and roots, the tissues of the tumbleweed structure are dead
https://homeguides.sfgate.com/examples-plants-disperse-seeds...
https://m.youtube.com/watch?v=b5JicZvq8TQ
But I removed the example because at that point I was talking about parts of plants rather than seeds. I don't actually know of an example of a plant hurling away a non-seed part of itself for budding, though I'd be surprised if it doesn't exist.
But can you imagine during a strong windstorm, how much farther these seeds would go? Especially fall windstorms. The wind is doing 20mph, and then these seeds go flying up in the air...
Neat.
People are just being too pedantic and nerdy of the use of the term. Of course one word cannot explain the technical aspect of how it actually works, that's why we use the term. It describes the general principle of how it works.
Article is blaming a misconception on the terminology. Terminology is correct. DNS actually uses both push and pull for different parts of propagation, in fact.
Google's 8.8.8.8: https://developers.google.com/speed/public-dns/cache
Cloudflare's 1.1.1.1: https://1.1.1.1/purge-cache/
Invalidating the cache at one doesn't invalidate the cache downstream of them if they already looked the record up recently. But it does mean that anyone who hadn't looked up the record will get the correct result straight away.
2) What if we purge 1.1.1.1 at 1.1.1.1 ?
3) What if we purge both about the other at the same time?
4) What if we purge aaaaaaa!
So much time...so many ideas...are they sure they will end up well?
And it's not like they need to hold on to any state to work. If you had access you could purge everything and have them start fresh from the root servers, and it would work fine. (As long as the load spike doesn't make it decide to do something dumb, of course.)
8.8.8.8 isn't a DNS name, it's an IP address. There's nothing to purge.
dns.google from dns.google
one.one.one.one from one.one.one.one
dns.google and one.one.one.one
The URL above is the documentation of the feature, which happens to also embed it.
It's like correcting someone for saying lightning struck something on the ground, even though the current starts on the ground and "strikes"up at the sky. Even though the ground is "pushing" the lighting bolt up to the sky, it's the conditions of the sky that led to the ground push the current upwards.
https://en.m.wikipedia.org/wiki/Lightning_strike
Actual moving positive charges (e.g. ions in solution) do move in the direction of "current".
Why do slow-mo lightning shots clearly show the opposite then? Unless you're referring to "conventional current", which is about as pedantic as you can get given that that's an obsolete and incorrect school of thought based around flow of positive charges before electrons were discovered.
For the average non-technical user, it's fine to use the "propagation" explanation. It's easy to understand, and it does describe the result the user sees, even if it gets the mechanism wrong. But the propagation explanation has become so widespread and ingrained that technical people who need to know the correct explanation often don't, and don't even realize that they've had the wrong information for years.
A single word isn't going to tell you exactly how something so technical works, but it is the most correct term to use to describe what is occurring.
It is completely pedantic.
I think propagation it's highly descriptive. You make a change and then you wait for various DNS servers to acknowledge that change (once cached records expire).
Worse yet, now all DNS software is the same. Some caching dns servers still do the query every time. It's just that you answer with cache so it's fast. Some DNS servers will fail once and then near immediately be fixed.
Since it's such a complicated subject. It's better to generalize and simplify as 'propagate'.
> DNS is pull, not push
Except for when it is.... If you increment the serial number of a zonefile on your authoritative ns1 and reload the zone, it will push it to any slaves that are configured and set as authoritative for the zone. Very standard IXFR config.
If we are referring to third parties' caching recursive resolvers updating a zone, then yes, it absolutely is pull not push.
Otherwise, this is just a simple misunderstanding about which systems are clients in the relationship, which I suppose is less fun to write a blog about.
But "it" here doesn't include every DNS server, right? Because, e.g., djbdns definitely doesn't do any pushing when you rebuild the database. And PowerDNS has "native replication" mode where there's no pushing done by the server on changes.
This shows a fundamental misunderstanding. It has nothing to do with push or pull. It also has nothing to do with when the information was propagated - before the request had been made or afterwards.
When you attempt to resolve a website's IP address from a URL, that is almost never done by sending a request to the authoritative server that owns that particular bit of information but to a caching resolver that requires the data gets propagated from the other server.
Cached records mean the next request will result in a cache miss, and so a higher level request up the chain.
When that happens, a record is copied down the chain. Regardless of the mechanism, the data is now propagating.
Shameless plug: To view your DNS 'propagation' (or whatever you want to call it) in 'realtime' check out dug!
https://dug.unfrl.com
https://github.com/unfrl/dug