Don't say "propagation" in DNS

Most DNS providers have a “propagation time” that governs how long it takes from the time you update a DNS record until it’s available on all of their servers. It can be hard to measure this because they often also use anycast, which means multiple servers can have the same IP address, and depending on where you are in the world you might talk to a different server (and get a different answer) than Let’s Encrypt does.

There is a technical misstatement on Challenge Types - Let's Encrypt : there is no concept of "propagation" in DNS in the context of TTL.

There is "propagate" as a technical term in DNS, but it refers to the behavior of a zone transfer from a primary to a secondary. see RFC 1912.

For more information on the claims made in this topic, see DNS propagation does not exist.

I am not going to tell the staff to fix anything immediately, but please be careful when reviewing existing articles or writing new ones in the future.

1 Like

This section of the article is referring to propagation delays within a DNS provider, which do exist, not to the concept of propagation to the rest of the Internet (which you're correctly pointing out is mostly a misunderstanding). I do see what you mean about this overlapping with the technical, RFC 1912 use of the word "propagate." We'd gratefully accept suggestions / pull requests to make this paragraph more technically correct while still being as clear as possible for its audience.

9 Likes

@JamesLE Oops, sorry about that. I'm glad to see that you have a rigorous understanding of the terminology. I apologize for the inconvenience.

6 Likes

@JamesLE Again, I have a question.

Most DNS providers have a “propagation time” that governs how long it takes from the time you update a DNS record until it’s available on all of their servers.

I understand that there is a delay between setting the DNS records and being able to retrieve DNS information. On top of that, does the DNS provider really have a "propagation time" setting? If I'm not mistaken, I don't think it is possible to control such a delay time.

I couldn't understand the meaning of this first line and started this kind of thread.

1 Like

Yes, it's the SOA refresh field.

But I must say that serious dns providers are mostly instantaneous and they only ever expose the same info on all nameservers.

5 Likes

@JamesLE All right! There is no problem with the English text in that section, but there is a problem with the text on the Japanese page.

  • (bad)
    • チャレンジのタイプ - Let's Encrypt - フリーな SSL/TLS 証明書
    • ほとんどの DNS プロバイダには、DNS レコードを更新してからプロバイダのサーバー全体に情報が反映されるまでの時間を定める「伝搬時間 (propagation time)」が設定されています。
    • It means: there is a setting to determine the "propagation time".
  • (good)
    • ほとんどの DNS プロバイダでは、DNS レコードを更新してからプロバイダのサーバー全体に情報が反映されるまでゾーン転送における「伝播時間 (propagation time)」の遅延が生じます。
    • It means: there is a propagation time that can cause delays.
    • NOTE: propagation is "伝播" not "伝搬" in Japanese.

I have shown you a more appropriate Japanese sentence. Best regards.

4 Likes

With the DNS-01 challenge, LetsEncrypt checks the domain's authoritative name servers directly - it does not consider any public DNS servers, nor does it consider any DNS servers in their ISP's infrastructure.

DNS within many providers is a "black box" mystery and often changes as their internal architecture does. Once a customer edits a record, it is impossible to guess when that change will become "publicly available" on their own servers. Consumers are generally not able to affect this at all.

These are some of the more common variants I have seen providers implement within their infrastructure. When a customer edits a record:

  • update all public facing DNS servers immediately. :partying_face:
  • implement a write-through cache between public facing DNS servers and a database backend :partying_face:
  • do not update public facing DNS servers at all, and rely on an internal TTL of 60s to 300s
  • update a database backend, but not public facing DNS servers
  • have a tiered internal DNS system across their networks, that may or may not have a TTL of 60s to 300s
  • implement a read-through cache between public facing DNS servers and a database backend.
  • implement a read-through cache, but the duration is not based on the TTL, and instead on their private application configuration setting
  • offer customers a chance to, once or twice daily, flush all DNS records from their servers and systems, so the next hits refresh off the database backend

One of the most infuriating patterns is when several of these variants are implemented in the same system. I recall one provider had users enter challenges on their api/admin-console, which updated their database backend, but their public facing dns servers used a read-through cache with a 300s expiry. it seemed the cache was based on the registered domain - not queried domain - so any dns queries for that domain would prime the cache - so LetsEncrypt would almost always see an old value. Another provider had a similar system, but the cache was on the queried domain - a failed LetsEncrypt authorization meant the cache was guaranteed to serve the wrong record for 5 minutes. The only way to utilize LetsEncrypt on those systems, was to "sleep" for 301 seconds after updating a record.

7 Likes

Another annoying variation I've seen is that the DNS changes get saved to some sort of DB back end, but the changes are only flushed to the public DNS servers on a fixed interval which can be anywhere from 15 min to multiple hours. The customer has no control over this interval.

4 Likes

Thank you! I've submitted your suggestion as a comment on our translation platform, Crowdin, for the attention of our localization volunteers and our communications team.

7 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.