DNS doesn't “propagate” | Hacker News Reader

DNS doesn't “propagate”

jvns.ca

229 pointsrg111151 comments

"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.)

Zombie plants?

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

Still relies completely on wind. There are plants with spring-loaded seeds that will fling them various distances:

https://homeguides.sfgate.com/examples-plants-disperse-seeds...

https://m.youtube.com/watch?v=b5JicZvq8TQ

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.

Those spider like plants, send a vine out with a plant. It takes time, weeks, but that's fast plant movement...

Oh right, that's a great point. In fact, that's probably one of the most common forms of non-seed propagation. Strawberries, mint, blackberries, etc.

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...

Neat.

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.

Hmm, neat.

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.

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/

OpenDNS: https://cachecheck.opendns.com/

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.

1) What if we purge 8.8.8.8 at 8.8.8.8 ?

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?

You purge domains, not IPs.

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.)

> 1) What if we purge 8.8.8.8 at 8.8.8.8 ?

8.8.8.8 isn't a DNS name, it's an IP address. There's nothing to purge.

I realize that. Sorry...I meant to say

dns.google from dns.google

one.one.one.one from one.one.one.one

I guess the downvotes are about 1 and 2 but ok, I meant

dns.google and one.one.one.one

FYI There's an easier-to-remember URL for Google: https://dns.google/cache

The URL above is the documentation of the feature, which happens to also embed it.

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.

While ground to cloud strikes do happen, they’re less common than cloud to ground strikes.

https://en.m.wikipedia.org/wiki/Lightning_strike

Electrons always flows negative to positive.

"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.

https://youtu.be/qQKhIK4pvYo?t=411

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.

It is completely pedantic.

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 didn't know the word 'propagation' implied a specific method by which data is propagated (push/pull).

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.

> 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.

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.

That isn't how organisms reproduce, either.

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.

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. 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.

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.

100% agree.

Sometimes on HN or forums people like to take the words we use to simplify and say "it doesn't really do that" then have some philosophical story behind it all, that is just too pedantic. Similar to how I saw a conversation here the other day saying that "homeless" isn't the correct term anymore for someone who is without a home.

Too pedantic IMO.

I think in this case it's a bit different than what you describe. Using the "propagation" example when talking to non-technical users is probably fine, because they just need to understand the concept that their resolver and their friend's resolver might not agree on the record's value for a while. "Propagation" is a very simple way of making the result easily understandable without having to go into a more technical discussion (that could take longer and perhaps not end up being understood very well at all).

But for technical people, the "propagation" explanation is actively harmful, because they might actually need to understand the mechanism of caching in order to do their work properly. And any technical person should be able to quickly grasp the idea of cache expiration being the reason why different clients can still see the old value for a time.

I don't think pedantry comes into the equation for this at all.

I think it does, this is all based on your target audience.

Using the term propagate is fine, because what is it to propagate anyway? and because of that, the devils' in the detail after all. Of course in technical terms the way that the records propagate is via the updating of cached records. But that is the mechanism in which DNS propagates.

You said it yourself, it's a fine to non-technical users. But of course, one single word cannot encapsulate how something actually works at a technical level.

We're being pedantic about how the word applies to how DNS records work, but it is the best option. Given that the author couldn't suggest an alternative, I feel that we're being too technical and nerdy of the use of the word.

Heck, Rackspace, Cloudflare and ICANN all use the the term propagate. ICANN even use it in their functional requirements.

I have been able to send https://www.whatsmydns.net/ to customers helps a ton

> 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.

Cached records expiring doesn't "propagate" or "pull" or "push" anything.

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.

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.

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.

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.

This is described in section "okay, DNS records actually do “propagate”."

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.

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.

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

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/.

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/

There is a logical topology though, no?

> 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.

1. Propagation implies no such thing.

2. As with the OP, the content marketing piece referenced fails to discuss the DNS beyond resolver activity, and thereby presents the same painfully half-baked construction of the system.

But there is a physical or logical topology through which it spreads?

> 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.

> 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.

Keep reading; that point is addressed a few paragraphs lower in the post.

Sure, but higher up, the post is spouting technically incorrect information.

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.

Exactly - it acts like propagation and cache invalidation is a very hard problem, one of the two.

This post brought to you by mavengang.

and it handles the names of things. No wonder DNS is hard.

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

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.

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)

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

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.

And then only hope all DNS servers in the chain, up to your router or ISP properly adhere to the set TTL.

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.

> I have no idea how DNS worked in the 90s though.

Not sure also, but in the 00s hosting/registrar control panels were notoriously bad at updating their server configs for some reason. It was not uncommon to wait ~30-60 minutes for the changes to be pushed to the authoritative servers and my guess is that for older IT folks that's where all 'propagation' expectations come from.

Propagation is just cache expiration under time reversal symmetry

When I propagate a plant I am literally pulling (well, cleanly cutting) a part off of the plant. A non-zero cost clone if you will. Propagation seems appropriately descriptive; as in, I'm pulling from a source to have a local copy - without telling the full story.

The fiction (useful or otherwise) seems to be the use of propagation to explain why updates don't appear immediately. One doesn't follow from the other, as in, you'll always get the most recent information from your source . . . but have you considered TTLs?

A useful fiction is always a stepping stone to a more fulsome understanding.

All in all, a good article that takes another step past the fiction of propagate.

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'.

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.

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?

>Your registrar has to tell your TLD’s nameservers about the new nameservers for your domain (I don’t know exactly how long this takes or why it takes time, but it’s not instant!)

How does this process work? Do the registrars push to the TLDs? Or do the TLDs pull from the registrars? Is there some other protocol / infrastructure besides DNS for managing this kind of updates?

Registrars interface with registries using a protocol called EPP (see RFC 5731 for the bit relevant to domains), generally speaking. They perform updates to domains by sending a domain:update request to the registry's EPP endpoint. There are some complications depending on whether registries treat nameservers are attributes of a domain or independent objects, but that's the gist of it.

Behind the scenes, the registry will update their nameservers to reflect the updated nameserver list for the domain.

Registries don't pull from registrars.

September really is eternal.

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.

as the author of https://github.com/JulienPalard/dnswait I agree \o/

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.

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.

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

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.

That's nothing. The confusion I had when finding out that zone files, ending in .db, weren't Berkeley DB files, lasted for months.

"zone files ending in .db, from the Berkeley Internet Name Daemon," I should have said.

> 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.

AIUI some resolvers will set a lower bound on TTLs.

But what are "some" resolvers? I never saw one of those commonly in use.

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.

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.

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.

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.

Don't really know how accurate this is, but I remember reading about some resolvers ignoring too low TTLs.

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!

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.

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.

Interesting, is there a word for pull-based propagation? I’d always assumed it was the same word.

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.

"SQL" originally stood for Structured Query Language

Does it not anymore? Or is it like KFC?

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.

It depends on what you mean by propagate.

So DNS propagation is the internet's version of "different areas on your tongue are responsible for different tastes" myth...

Seems like semantics. Propagate means to spread. Seems accurate to me.

Also, water is not wet.

> 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.

Then the article should be titled "DNS doesn't push". Claiming it doesn't propagate is bizarre.

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.

Propagation fairly strongly implies something emanating from a source.

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.

> am I not propagating the ideas written on it

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.

Who said anything about propaganda? Not all ideas are classified that way, and I was talking about writing a book, not dropping leaflets.

Indeed. But the reason propaganda is called such is because it's an information push - to propagate (same root word) rather than publish information.

> 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...

Which, again, just translates to "but it can take up to 48 hours for other nameservers to have caught up".

Those are both true statements. They also don't imply a push model.

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.

You're the one making the distinction.

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.

Yes. It’s the effect that propagates.

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.

Can news propagate?

If someone claimed that in 48 hours everyone on the planet would've heard some news, that would imply a push, yes.

"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.

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.

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".

Andy Rooney made a career out of nitpicking commonly accepted declarative english statements and commonalities in the language.

> 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/

Your personal semantic disagreement (which per responses is clearly not the only way to see things) does not make an article clickbait.

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.

Reply on news.ycombinator.com