1. 37
  1. 14

    Part of the argument here is over the transitive and intransitive meanings of propagate - see https://en.m.wiktionary.org/wiki/propagate

    The transitive form (I propagated a message) implies push mechanism. The intransitive form (the message propagated) is consistent with any flow of information, whether a push or pull mechanism, especially if viewed at a higher level of abstraction.

    1. 6

      I guess the fine difference in meaning is lost to me as a non-native speaker. If it arrives (or not) but is discarded immediately, it has not propagated. I wouldn’t even think to ponder if it’s push or pull. Either it wasn’t pushed, wasn’t pulled, or was pushed and ignored or was pulled and ignored.

      1. 16

        Propagate is used all the time in English without any sort of ‘push’ semantics. I think the assertion that DNS doesn’t “propagate” will get caught up in quibbles over various people’s understandings of the word, whether they’re native speakers or not. A better title might avoid the confusion by talking about push vs pull explicitly.

        1. 5

          Propagate can be used to any kind of information transfer, with push, pull, or other semantics.

          1. 4

            I said above that to me it suggested some kind of push mechanism, but I guess what’s confusing about it is not so much push vs. pull, but the implication that anything necessarily gets transferred at all – propagate definitely implies motion, whereas what’s really happening is cache entries are expiring. “Propagating” suggests that it’s something that new (not already cached) entries have to do too, but they don’t, because that’s not what’s happening. You could probably argue that there’s something more abstract that is “propagating” here, but the point is that the term generates the wrong intuitions.

        2. 10

          As a native speaker, it is a bit ambiguous, but “propagate” definitely feels more like it implies push, and I agree with the author that I think it’s misleading. In any case, this is definitely something I’ve seen people confused about a lot, trips people up a lot, and having a correct mental model is really useful.

          1. 3

            Not a native speaker and I see where the push/pull similarity comes in. However I think the main expectation for me for “propagate” is that the name would end up on other servers (whether they pull for updates, or it gets pushed), even without me asking for the resolution. If I have to trigger the process by asking -> no propagation.

            1. 2

              Yeah, this is a bit more precise; see my other comment:


          2. 5

            There are lots of native speakers who would also disagree with this post. Propagation is not a “wrong” word, and while it’s true that a lot of people are confused about how DNS works, a quick terminology hack isn’t going to do much about that.

            1. 2

              I guess for me the term “propagate” doesn’t say anything about pull vs push, but does have connotations of filtering through multiple layers. DNS doesn’t really do this either—layered caches only really exist within individual networks, and anyway DNS cache expiration is absolute, occurring simultaneously at every level. So I’ve often considered the term to be misleading because it seems to imply some sort of gradual spread, when the reality is more point-to-point.

            2. 5

              I’ve come across co-workers and other people misunderstanding this quite some times. It’s sometimes important to know that waiting for expiration is mostly relevant if you do changes as in “updates” and “replacing” entries.

              Whereas, if you just add a new entry, say an A-record adding a host this should happen instantly. Most software isn’t caching NXDOMAIN (the negative caching in the article). Even though I have come across software that does, however that wasn’t a remote DNS server.

              On a related note. If you have to change/replace entries it might make sense to change TTL to something low beforehand. That can reduce the amount of headache, when something goes wrong.

              While I think “propagation” could be considered technically correct in the sense that it becomes more and more available and in a way propagates through caches, I also think it gives a bad mental model. It’s simply not clear. We also don’t say that for example static assets on the web propagate through proxies and browser caches, even though one can use HTTP proxies/caches in a very similar way.

              1. 6

                Most software isn’t caching NXDOMAIN

                Fwiw I’ve seen a lot of caching DNS servers do cache NXDOMAIN, sometimes I think more aggressively than they are supposed to. You only need one caching DNS server to be holding onto an NXDOMAIN for the domain to be inaccessible to thousands of people who are using that DNS server.

                1. 1

                  I always thought “your DNS change hasn’t propagated” was just something you had to tell customers so as not to have to explain cache expiry to them. And in particular, to not have to explain why their dialup ISP only expires cached DNS entries in its own sweet time instead of what it says in the zone file.

                2. 2

                  Mostly a decent article, just one nit on a scenario which is false and a little dangerous for the tiny tiny few people using it, and one confirmation.

                  Yes, back before NOTIFY support was common, initial DNS update propagation delays could be quite slow. That’s what many of the fields in the SOA record are all about: how often should secondaries poll to see if there’s an update (newer serial number) and if they fail to ask, or fail to transfer, how long they should try again for, and how long to keep serving data if the primary disappears forever.

                  So with a 1hr refresh and 5 minute retry, you might wait up to an hour for changes to be available in response to all queries, and that’s assuming that the initial request was successful, but then 65 minutes for some servers to update, etc.

                  But as long as all authoritative servers are correctly listed in-zone, the primary authoritative server can auto-determine the others with no more configuration and send NOTIFY; the retry timers then only apply to those servers which missed the initial UDP packet, and if your deploy logic doesn’t poll them and re-issue NOTIFY as needed.

                  The dangerous bit: for a new host record, a cached negative entry is fine, it just means some people won’t see the new host for a bit longer. But for outbound transactions, where you need to refer to an identifier in DNS, you can’t start doing so until it’s safe to assume that any client should be able to see the new identifier. So, if you use a predictable naming pattern for things like DKIM signing keys, then a malicious actor could get popular resolvers to negative-cache the TXT record for the new keys when they’re due, and if you’ve immediately switched to signing outbound mail with the new key, then some recipients will see bad signatures and reject or classify as spam, etc.

                  There are other similar scenarios; the key point is that impact depends upon who makes the choice to start using the name and what the impact is when it doesn’t exist. And in these scenarios, you do need to worry about the resolvers which over-aggressively hold onto negative cache entries. So it just means that for records with lifetimes of months, you might create the keys and populate the DNS a full day ahead of switching to signing with the new keys.

                  1. 1

                    DNS does propagate but you don’t normally see it because the push side is mostly pretty much automatic. It also tends to work well for external DNS which is relatively stable. If you run DNS infrastructure then your records have to propagate to your DNS servers. Clients pull your records from your servers and without caching, that would be automatic. But you always have to push your records to your servers. One path:

                    • You update the record within the zone and the zone’s SOA record on your primary DNS server. The field in the SOA record that’s sometimes formatted as yyyymmdd## is called the serial field. It’s supposed to increase with every change you make to the zone. The last part is important because that change tells your dns servers that the zone records have changed and need to be updated.
                    • Your primary DNS server recognizes the new zone and sends a notify event to your secondary DNS servers. They recognize the notify and pull the changes or the whole zone.

                    At this point new queries to the subset of your secondary DNS servers that understand notify will return the new records. You may have servers that don’t/can’t do notify. It’s rare but it happens. Think, for example, VPN tunnels that aren’t up all the time. The path for secondary DNS servers that don’t understand notify is different:

                    • These servers poll the primary server periodically asking for the SOA records for each zone that they mirror. The periodicity of this poll is controlled by the refresh, retry, and expire fields in the SOA record.
                    • When the serial field in the newly fetched SOA record is greater than the serial field that they have, the secondary server will pull the zone from the primary server.

                    Note also that this is mechanism that propagates the changes when the notify message doesn’t get delivered for whatever reason. Just remember that DNS notify messages are sent over UDP so your primary DNS server may not know that your secondary didn’t get the message.

                    Proper DNS is really important part of running an organization. One way to make things easier is to put internal DNS servers in strategic locations within your infrastructure. A downside to this is that you increase your risk of seeing the effects of a lost UDP notify packet.