14 ms·

DNS doesn't “propagate”

229 points by rg111 5y ago

robertlagrant 5y ago
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 5y ago
  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.
wz366 5y ago
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.
maxgashkov 5y ago
> 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.
Simplicitas 5y ago
"SQL" originally stood for Structured Query Language
- foo92691 5y ago
  Does it not anymore? Or is it like KFC?
Panino 5y ago
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 5y ago
  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.
tyingq 5y ago
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.
- threeio 5y ago
  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
- deleted 5y ago
  [deleted]
northisup 5y ago
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 5y ago
  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 5y ago
    and it handles the names of things. No wonder DNS is hard.
bfa490812b16 5y ago
What does "propagate" mean?
- bfa490812b16 5y ago
  Lol. The core question isn't answered. This place is such a cesspool.
trixie_ 5y ago
I didn't know the word 'propagation' implied a specific method by which data is propagated (push/pull).
- ranger207 5y ago
  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
- mkishi 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - j4yav 5y ago
    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 5y ago
      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.
sebazzz 5y ago
And then only hope all DNS servers in the chain, up to your router or ISP properly adhere to the set TTL.
wruza 5y ago
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-and-networking/clearing-the-dns-cache-on-your-computer https://www.a2hosting.com/kb/getting-started-guide/internet-... (How to clear the DNS cache on your computer: win, osx, linux)
- 10000truths 5y ago
  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
- laumars 5y ago
  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.
meetups323 5y ago
> 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.
- agentdrtran 5y ago
  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 5y ago
    Then the article should be titled "DNS doesn't push". Claiming it doesn't propagate is bizarre.
    - mgiampapa 5y ago
      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 5y ago
      Propagation fairly strongly implies something emanating from a source.
mindslight 5y ago
"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).
sfink 5y ago
(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.)
- b112 5y ago
  Zombie plants?
  - jodrellblank 5y ago
    Tumbleweed, possibly: https://en.wikipedia.org/wiki/Tumbleweed 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
    - Izkata 5y ago
      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-shooting-70888.html https://homeguides.sfgate.com/examples-plants-disperse-seeds... https://m.youtube.com/watch?v=b5JicZvq8TQ https://m.youtube.com/watch?v=b5JicZvq8TQ
motohagiography 5y ago
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.
j4yav 5y ago
Interesting, is there a word for pull-based propagation? I’d always assumed it was the same word.
- SomeCallMeTim 5y ago
  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.
Railsify 5y ago
It depends on what you mean by propagate.
julienpalard 5y ago
as the author of https://github.com/JulienPalard/dnswait https://github.com/JulienPalard/dnswait I agree \o/
isclever 5y ago
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 https://developers.google.com/speed/public-dns/cache Cloudflare's 1.1.1.1: https://1.1.1.1/purge-cache/ https://1.1.1.1/purge-cache/
- brycewray 5y ago
  OpenDNS: https://cachecheck.opendns.com/ https://cachecheck.opendns.com/
- Hamuko 5y ago
  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 5y ago
    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 5y ago
      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).
      - lathiat 5y ago
        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.
wefarrell 5y ago
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.
- laumars 5y ago
  While ground to cloud strikes do happen, they’re less common than cloud to ground strikes. https://en.m.wikipedia.org/wiki/Lightning_strike https://en.m.wikipedia.org/wiki/Lightning_strike
  - annoyingnoob 5y ago
    Electrons always flows negative to positive.
    - Thrymr 5y ago
      "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".
- riffic 5y ago
  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.
- s0ulphire 5y ago
  https://youtu.be/qQKhIK4pvYo?t=411 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.
gclawes 5y ago
Propagation is just cache expiration under time reversal symmetry
sleepysysadmin 5y ago
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'.
harel 5y ago
So DNS propagation is the internet's version of "different areas on your tongue are responsible for different tastes" myth...
birdyrooster 5y ago
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.
walrus01 5y ago
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.
- kelnos 5y ago
  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.
  - BeefWellington 5y ago
    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.
- bingo-bongo 5y ago
  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.
- NoWayDude1 5y ago
  This is described in section "okay, DNS records actually do “propagate”."
- zimpenfish 5y ago
  > 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.
IncRnd 5y ago
> 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.
- Nevermark 5y ago
  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.
  - IncRnd 5y ago
    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.
nickdothutton 5y ago
September really is eternal.
monkaiju 5y ago
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://dug.unfrl.com https://github.com/unfrl/dug https://github.com/unfrl/dug
micw 5y ago
> 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.
- lilyball 5y ago
  AIUI some resolvers will set a lower bound on TTLs.
  - micw 5y ago
    But what are "some" resolvers? I never saw one of those commonly in use.
- Anthony-G 5y ago
  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.
- jedberg 5y ago
  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 5y ago
    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.
richardwhiuk 5y ago
> 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 5y ago
  Keep reading; that point is addressed a few paragraphs lower in the post.
  - richardwhiuk 5y ago
    Sure, but higher up, the post is spouting technically incorrect information.
uvdn7 5y ago
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/ https://blog.the-pans.com/dns/.
- pul 5y ago
  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/ https://www.nslookup.io/blog/dns-propagation-does-not-exist/
  - NoPicklez 5y ago
    But there is a physical or logical topology through which it spreads?
  - bottled_poe 5y ago
    There is a logical topology though, no?
  - Dylan16807 5y ago
    > 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.
  - inopinatus 5y ago
    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.
- 5y ago
ushtaritk421 5y ago
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?
1MachineElf 5y ago
Also, water is not wet.
Twisol 5y ago
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.
jeofken 5y ago
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_ 5y ago
  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.
mrmattyboy 5y ago
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.
awestley 5y ago
Seems like semantics. Propagate means to spread. Seems accurate to me.
icedchai 5y ago
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.
- NoPicklez 5y ago
  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.
  - kelnos 5y ago
    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.
    - NoPicklez 5y ago
      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.
neurobashing 5y ago
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.
gjvc 5y ago
That's nothing. The confusion I had when finding out that zone files, ending in .db, weren't Berkeley DB files, lasted for months.
- gjvc 5y ago
  "zone files ending in .db, from the Berkeley Internet Name Daemon," I should have said.
earleybird 5y ago
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.
aftbit 5y ago
>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?
- talideon 5y ago
  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.
deleted 5y ago
[deleted]

229 points by rg111 5y ago

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 5y ago
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.

wz366 5y ago

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.

maxgashkov 5y ago

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

Simplicitas 5y ago

"SQL" originally stood for Structured Query Language

foo92691 5y ago
Does it not anymore? Or is it like KFC?

Panino 5y ago

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 5y ago
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.

tyingq 5y ago

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.

threeio 5y ago
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
deleted 5y ago
[deleted]

northisup 5y ago

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 5y ago
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 5y ago
  and it handles the names of things. No wonder DNS is hard.

bfa490812b16 5y ago

What does "propagate" mean?

bfa490812b16 5y ago
Lol. The core question isn't answered. This place is such a cesspool.

trixie_ 5y ago

I didn't know the word 'propagation' implied a specific method by which data is propagated (push/pull).

ranger207 5y ago
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
mkishi 5y ago
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.
- deleted 5y ago
  [deleted]
- j4yav 5y ago
  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 5y ago
    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.

sebazzz 5y ago

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

wruza 5y ago

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-and-networking/clearing-the-dns-cache-on-your-computer https://www.a2hosting.com/kb/getting-started-guide/internet-... (How to clear the DNS cache on your computer: win, osx, linux)

10000truths 5y ago
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
laumars 5y ago
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.

meetups323 5y ago

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

agentdrtran 5y ago
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 5y ago
  Then the article should be titled "DNS doesn't push". Claiming it doesn't propagate is bizarre.
  - mgiampapa 5y ago
    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 5y ago
    Propagation fairly strongly implies something emanating from a source.

mindslight 5y ago

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

sfink 5y ago

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

b112 5y ago
Zombie plants?
- jodrellblank 5y ago
  Tumbleweed, possibly: https://en.wikipedia.org/wiki/Tumbleweed 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
  - Izkata 5y ago
    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-shooting-70888.html https://homeguides.sfgate.com/examples-plants-disperse-seeds... https://m.youtube.com/watch?v=b5JicZvq8TQ https://m.youtube.com/watch?v=b5JicZvq8TQ

motohagiography 5y ago

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.

j4yav 5y ago

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

SomeCallMeTim 5y ago
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.

Railsify 5y ago

It depends on what you mean by propagate.

julienpalard 5y ago

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

isclever 5y ago

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 https://developers.google.com/speed/public-dns/cache Cloudflare's 1.1.1.1: https://1.1.1.1/purge-cache/ https://1.1.1.1/purge-cache/

brycewray 5y ago
OpenDNS: https://cachecheck.opendns.com/ https://cachecheck.opendns.com/
Hamuko 5y ago
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 5y ago
  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 5y ago
    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).
    - lathiat 5y ago
      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.

wefarrell 5y ago

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.

laumars 5y ago
While ground to cloud strikes do happen, they’re less common than cloud to ground strikes. https://en.m.wikipedia.org/wiki/Lightning_strike https://en.m.wikipedia.org/wiki/Lightning_strike
- annoyingnoob 5y ago
  Electrons always flows negative to positive.
  - Thrymr 5y ago
    "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".
riffic 5y ago
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.
s0ulphire 5y ago
https://youtu.be/qQKhIK4pvYo?t=411 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.

gclawes 5y ago

Propagation is just cache expiration under time reversal symmetry

sleepysysadmin 5y ago

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

harel 5y ago

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

birdyrooster 5y ago

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.

walrus01 5y ago

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.

kelnos 5y ago
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.
- BeefWellington 5y ago
  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.
bingo-bongo 5y ago
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.
NoWayDude1 5y ago
This is described in section "okay, DNS records actually do “propagate”."
zimpenfish 5y ago
> 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.

IncRnd 5y ago

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

Nevermark 5y ago
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.
- IncRnd 5y ago
  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.

nickdothutton 5y ago

September really is eternal.

monkaiju 5y ago

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://dug.unfrl.com https://github.com/unfrl/dug https://github.com/unfrl/dug

micw 5y ago

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

lilyball 5y ago
AIUI some resolvers will set a lower bound on TTLs.
- micw 5y ago
  But what are "some" resolvers? I never saw one of those commonly in use.
Anthony-G 5y ago
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.
jedberg 5y ago
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 5y ago
  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.

richardwhiuk 5y ago

> 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 5y ago
Keep reading; that point is addressed a few paragraphs lower in the post.
- richardwhiuk 5y ago
  Sure, but higher up, the post is spouting technically incorrect information.

uvdn7 5y ago

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/ https://blog.the-pans.com/dns/.

pul 5y ago
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/ https://www.nslookup.io/blog/dns-propagation-does-not-exist/
- NoPicklez 5y ago
  But there is a physical or logical topology through which it spreads?
- bottled_poe 5y ago
  There is a logical topology though, no?
- Dylan16807 5y ago
  > 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.
- inopinatus 5y ago
  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.
5y ago

ushtaritk421 5y ago

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?

1MachineElf 5y ago

Also, water is not wet.

Twisol 5y ago

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.

jeofken 5y ago

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_ 5y ago
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.

mrmattyboy 5y ago

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.

awestley 5y ago

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

icedchai 5y ago

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.

NoPicklez 5y ago
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.
- kelnos 5y ago
  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.
  - NoPicklez 5y ago
    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.

neurobashing 5y ago

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.

gjvc 5y ago

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

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

earleybird 5y ago

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.

aftbit 5y ago

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

talideon 5y ago
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.

deleted 5y ago

[deleted]