[HN Gopher] DNS doesn't "propagate"
___________________________________________________________________
DNS doesn't "propagate"
Author : rg111
Score : 163 points
Date : 2021-12-06 18:14 UTC (4 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| IncRnd wrote:
| > 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.
| j4yav wrote:
| Interesting, is there a word for pull-based propagation? I'd
| always assumed it was the same word.
| SomeCallMeTim wrote:
| It's also propagation.
|
| 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.
| uvdn7 wrote:
| This sounds like splitting hairs. Taking news as an example, when
| you say a piece of news propagates, are you implying push or
| pull? It doesn't imply either. The news spreads, either by
| someone telling someone else (push), or someone asking someone
| else (pull).
|
| Technically, a distributed database/cache at DNS scale, pure
| push-based invalidation is just not practical.
|
| I wrote a post about DNS invalidation earlier https://blog.the-
| pans.com/dns/.
| pul wrote:
| Even if you disregard push vs pull, 'propagation' still implies
| spread through proximity. That there would be some physical or
| logical topology through which it spreads. So, I agree with the
| OP. More details argumentation here:
| https://www.nslookup.io/blog/dns-propagation-does-not-exist/
| Dylan16807 wrote:
| > Even if you disregard push vs pull, 'propagation' still
| implies spread through proximity.
|
| I don't think so? Using the same example, I would say news
| propagates, and there is no specific topology it spreads
| through.
| bottled_poe wrote:
| There is a logical topology though, no?
| tomxor wrote:
| > propagates, are you implying push or pull? It doesn't imply
| either.
|
| I've always used the term "propagate" even though I understand
| it to be a pull system due to the existence of the TTL. Either
| way I hold no association between pull/push and "propagate" in
| my mind either.
|
| Maybe the author and their friend have some bias towards this
| definition, perhaps due to technical contexts they have most
| used that word within.
| Railsify wrote:
| It depends on what you mean by propagate.
| jeofken wrote:
| Here's my alternative explanation why the word "propagate" is
| used - there is no verb for awaiting cache TTL expiration.
|
| Some suggestions for verbs:
|
| * Cache flush wait
|
| * Cache out (sounds too much like "cash out")
|
| * Soft whisper / cache whisper
|
| * TTL cascade
| trixie_ wrote:
| The word propagate doesn't imply an active push as opposed to a
| passive pull. The author made an assumption that is outside the
| definition of the word 'propagate'. Either way the new
| information propagates through the network. The 24-48 hour
| window should be the first hint that a slower passive method is
| being used.
| meetups323 wrote:
| > 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.
| nimbius wrote:
| Andy Rooney made a career out of nitpicking commonly accepted
| declarative english statements and commonalities in the
| language.
| agentdrtran wrote:
| 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.
| meetups323 wrote:
| Then the article should be titled "DNS doesn't push".
| Claiming it doesn't propagate is bizarre.
| mgiampapa wrote:
| 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.
| robertlagrant wrote:
| Propagation fairly strongly implies something emanating
| from a source.
| cassianoleal wrote:
| 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.
| dreyfan wrote:
| > 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"
|
| [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...
| efdee wrote:
| Which, again, just translates to "but it can take up to 48
| hours for other nameservers to have caught up".
| meetups323 wrote:
| Those are both true statements. They also don't imply a push
| model.
| [deleted]
| dreyfan wrote:
| 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.
| whimsicalism wrote:
| You're the one making the distinction.
| dreyfan wrote:
| Am I? I don't have a horse in this race.
|
| 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.
| [deleted]
| tshaddox wrote:
| Yes. It's the _effect_ that propagates.
| [deleted]
| robertlagrant wrote:
| 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.
| whimsicalism wrote:
| Can news propagate?
| [deleted]
| Terry_Roll wrote:
| If you monitor the TTL changes in DNS records, you can spot
| when the best admins are going to be doing some major updates
| because the TTL decreases.
| lhorie wrote:
| > misleading clickbait at worst
|
| 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/
| jjoonathan wrote:
| 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.
| judge2020 wrote:
| > 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.
| [deleted]
| [deleted]
| sfink wrote:
| > 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".
| wonnage wrote:
| Your personal semantic disagreement (which per responses is
| clearly not the only way to see things) does not make an
| article clickbait.
| harel wrote:
| So DNS propagation is the internet's version of "different areas
| on your tongue are responsible for different tastes" myth...
| Simplicitas wrote:
| "SQL" originally stood for Structured Query Language
| foo92691 wrote:
| Does it not anymore? Or is it like KFC?
| ushtaritk421 wrote:
| So, how should I behave differently knowing that I'm not waiting
| for DNS to "propagate" but rather I'm waiting for DNS cached
| records to expire?
| mindslight wrote:
| "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).
| julienpalard wrote:
| as the author of https://github.com/JulienPalard/dnswait I agree
| \o/
| birdyrooster wrote:
| Lungs don't "respirate", they absorb oxygen from the inhaled air
| and pass it into the bloodstream in return for carbon dioxide
| which is then exhaled.
| isclever wrote:
| Google and Cloudflare allow anybody to expire any record in their
| cache, handy to have to if you make a mistake that is affecting
| customers.
|
| 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/
| Hamuko wrote:
| 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.
| fragmede wrote:
| 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.)
| dwild wrote:
| 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).
| brycewray wrote:
| OpenDNS: https://cachecheck.opendns.com/
| belter wrote:
| 1) What if we purge 8888 at 8888 ?
|
| 2) What if we purge 1111 at 1111 ?
|
| 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?
| wz366 wrote:
| Worked at AWS Route53, we do have record propagation, from record
| chanege requests to global edge servers. Records are updated in
| batch in an async way, but we try to keep the delay minimal and I
| sometimes don't really notice it as user.
| tyingq wrote:
| Good observation, and well written article.
|
| 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.
| [deleted]
| threeio wrote:
| 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
| walrus01 wrote:
| Header in the article:
|
| > 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.
| northisup wrote:
| 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.
| bombcar wrote:
| Exactly - it _acts_ like propagation and cache invalidation is
| a very hard problem, one of the two.
|
| This post brought to you by mavengang.
| coenhyde wrote:
| and it handles the names of things. No wonder DNS is hard.
| mrmattyboy wrote:
| One comment about the "okay, DNS records actually do
| "propagate"."
|
| I assume he's talking about DNS notifications?
|
| If so, I wouldn't say they're only for big providers. It's useful
| for anyone who runs more than one DNS server (and even Microsoft
| DNS does this, I think).
|
| The basic idea being that you run a single 'master' DNS server
| and then send 'notifications' to the other authoritative DNS
| servers (the situations I'm used to, the master is 'hidden' and
| only the 'child' DNS servers are publicly accessible.
|
| _BUT_, even in this case, the notifies are 'pushed', but AFAIK,
| the 'child' servers still 'pull' the zone from the master.
| nickdothutton wrote:
| September really is eternal.
| monkaiju wrote:
| 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!
|
| https://dug.unfrl.com
|
| https://github.com/unfrl/dug
| micw wrote:
| > some resolvers ignore TTLs
|
| Is that really true? I have heard this so often but never seen it
| in reality, so I tend to take this as an urban legend.
| micw wrote:
| I was searching for some (no-anecdotal) evidence and found this
| study:
|
| https://labs.ripe.net/author/giovane_moura/dns-ttl-violation...
|
| Seems that increased TTL in resolvers is still a thing in 2021
| but it's a bit over-estimated. IMO it should not be considered
| when changing DNS. May their customers complain about the
| broken DNS every time a change is not "propagated" (sic!)
| there.
| fragmede wrote:
| This is easy to see if you've got decent visibility into your
| system. Have your DNS TTL already set to 300 seconds (the
| minimum). Switch your A records over to a new load balancer.
| It'll take far longer than 5 minutes for traffic to die down,
| and if your site is popular enough, traffic to your old load
| balancer will never fully die down.
| jedberg wrote:
| Absolutely. My friend worked for an ISP in Alaska. They set
| their TTL to 48 hours for all records regardless of what the
| DNS said, because they didn't have the bandwidth to pull
| updates more often than that.
|
| Also, when I worked at reddit I had to change the IP for
| reddit.com in 2007. I set up a cache on the old IP to redirect
| any old traffic. Also, a week before the switch I had pulled
| the TTL down to 5 seconds.
|
| After I made the change, only 40% of the traffic shifted after
| a minute. That means at least 60% of the people on the internet
| were ignoring my 5 second TTL if not more.
|
| After a day 10% of the traffic was still going to the old IP.
| It took more than 48 hours for 99% of the traffic to switch.
| And after a month I still had about 20 hosts hitting the old IP
| (probably scripts that were hard coded with the old IP).
|
| At Netflix we had similar issues with lots of stragglers when
| we changed IPs.
|
| So yeah, a lot of resolvers ignore TTL.
| micw wrote:
| I wonder what kind of ISP it was with to few bandwidth for
| proper DNS ^^
|
| And I'm really curious which other ISPs are running such
| setups that you had to deal with and for what reason they do
| so.
| jedberg wrote:
| A small ISP in the early 2000's. :)
|
| I don't really know the cause of the other problems, but
| I'm guessing it was mostly browser and OS caching and not
| ISP caching.
| watermelon0 wrote:
| Don't really know how accurate this is, but I remember
| reading about some resolvers ignoring too low TTLs.
| jedberg wrote:
| It's quite possible that the 5 second TTL was a foot-gun.
| It was best practice at the time but not necessarily the
| right thing to do!
| lilyball wrote:
| AIUI some resolvers will set a lower bound on TTLs.
| micw wrote:
| But what are "some" resolvers? I never saw one of those
| commonly in use.
| Anthony-G wrote:
| I also haven't come across this while working as a sysadmin for
| the past 10 years but I've read that broken resolvers (ignoring
| the TTL) provided by ISPs were more common back in the 90s.
| 1MachineElf wrote:
| Also, water is not wet.
| sfink wrote:
| (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.)
| bbarnett wrote:
| Zombie plants?
| jodrellblank wrote:
| Tumbleweed, possibly:
| https://en.wikipedia.org/wiki/Tumbleweed
|
| > 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
| wefarrell wrote:
| This is overly pedantic.
|
| 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.
| riffic wrote:
| 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.
| laumars wrote:
| While ground to cloud strikes do happen, they're less common
| than cloud to ground strikes.
|
| https://en.m.wikipedia.org/wiki/Lightning_strike
| annoyingnoob wrote:
| Electrons always flows negative to positive.
| Thrymr wrote:
| "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".
| bfa490812b16 wrote:
| What does "propagate" mean?
| bfa490812b16 wrote:
| Lol. The core question isn't answered. This place is such a
| cesspool.
| richardwhiuk wrote:
| > new DNS records are actually available instantly
|
| This isn't quite correct - NXDOMAIN responses can be cached, so
| if you create a new record, and you've already queried for it,
| you might get a cached response.
|
| In BIND, this is configured as a NXDOMAIN cache on the SOA record
| for the zone, but that's an implementation detail.
| re wrote:
| Keep reading; that point is addressed a few paragraphs lower in
| the post.
| trixie_ wrote:
| I didn't know the word 'propagation' implied a specific method by
| which data is propagated (push/pull).
| ranger207 wrote:
| 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
| inopinatus wrote:
| It doesn't.
|
| 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. This mechanism
| is not discussed, and indeed the word _zone_ does not appear at
| all in this article, which suggests to me that the author has
| themselves a half-baked view of the DNS.
| mftb wrote:
| "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.
| mkishi wrote:
| 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.
| j4yav wrote:
| 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.
| mkishi wrote:
| 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.
| Nition wrote:
| > It sounds like some people...
|
| I'd be that person. "Propagate" strongly implies a push
| model to me; parent-to-child reproduction like an organism.
| Talanes wrote:
| 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.
| [deleted]
| quadrifoliate wrote:
| > but I think "to propagate" is easily deemed an active
| engagement as opposed to a passive one
|
| It _does_ require active engagement though! The author points
| this out herself:
|
| > In fact, if you create a DNS record, it's possible that no
| DNS resolver will ever know about it! For example, I just
| created a record for a subdomain of jvns.ca that I will not
| tell you. Nobody will ever make a DNS query for that
| subdomain (I'm not going to make one, and you can't because I
| didn't tell you what it is!), so no resolver knows about it.
|
| i.e. the awareness of such a record won't "propagate" unless
| Julia tells us what it is, and we start requesting it, from
| resolvers which might or might not choose to cache their
| results. It is also true that individual resolvers (say, a
| fictional One & Done, Inc.) might choose to _never_ update
| their results, and will cache the IP forever. Naturally,
| people will stop using those resolvers :)
| sebazzz wrote:
| And then only hope all DNS servers in the chain, up to your
| router or ISP properly adhere to the set TTL.
| robertlagrant wrote:
| 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?
| aflag wrote:
| 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.
| wruza wrote:
| 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.
|
| 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)
| laumars wrote:
| 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.
| 10000truths wrote:
| Alternatively, you can use dig, which bypasses OS-level DNS
| caching/resolution, and explicitly use a resolver that will
| respect short TTLs: dig @8.8.8.8 +short aaaa
| mydomain.com
| gclawes wrote:
| Propagation is just cache expiration under time reversal symmetry
| Twisol wrote:
| It is a kind of propagation, in the same sense that traffic waves
| propagate backwards relative to the flow of traffic, but the
| distinction here is really a good one. "Propagation" as a term
| encompasses two classes of propagation, leaving the door open for
| learners to assume the wrong one.
| icedchai wrote:
| I worked at ISPs for many years, and have been running DNS
| servers since 1995. "Propagation" was a term we used to simplify
| explanations for end users. Generally, "it takes time for an
| update to show up because it is propagating." If we had to
| explain their site isn't working because caches need to expire,
| and it doesn't work for your friend yet because old values are
| still in his name-server's cache, etc. we'd be there all day.
| sleepysysadmin wrote:
| 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'.
| neurobashing wrote:
| A lot of people here talking about splitting semantic hairs/what
| it means to propagate/etc and not enough fond remembrances of
| when DNS really did take 48 hours - maybe more! - to update. Like
| at one point I remember being on the phone with the admins of a
| big dial-up, begging them to update sooner so we could fix a
| problem one of our customers was having.
|
| There was a time when computing resources were precious. Kids
| these days, I tell ya.
| Panino wrote:
| 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.
| wang_li wrote:
| 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.
| motohagiography wrote:
| 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.
| awestley wrote:
| Seems like semantics. Propagate means to spread. Seems accurate
| to me.
___________________________________________________________________
(page generated 2021-12-06 23:01 UTC)