bortmeyer.org/propagationについて、ここに記述してください。
http://www.bortzmeyer.org/dns-propagation.html (フランス語)
Googleによる英訳
Can we really talk about DNS "propagation"?
First draft of this article on February 14, 2012 Last updated on February 15, 2012
Online forums often refer to "propagation" of information stored in the DNS . For example, a sentence like "The information has been changed in the registry , it is now necessary to wait 24 to 48 hours for their propagation ". Is this term correct?
I do not think so. "Propagation" refers to a movement that takes place on its own, once the source has been modified. This is actually the operation of some network protocols such as BGP ( RFC 4271 ) or Usenet ( RFC 5537 ) where, once injected into the system, the new products spread in effect, without further intervention, from machine to machine, until to reach all the Internet.
But the DNS ( RFC 1034 ) does not work like this. It is pull and not push , that is to say that the information does not propagate itself but is requested by customers, resolvers. They then keep it in their cache and return to the authoritative servers when the duration of stay in the cache comes to an end. If a resolver did not have the information in his cache, he asks for it and he will immediately have the information up to date, without "propagation". If it has it in its cache, waiting for a hypothetical propagation will not change anything, the new information will not arrive before the expiration of the data.
Note in passing that this expiration is controlled by the source: it indicates in the data the TTL , that is to say the lifetime of the data. The source (the authoritative server) can therefore perfectly control the update process, unlike what happens for BGP , where the original router has no influence on the propagation. It is because the source (the authoritative domain) chooses the TTL that it is possible (and even recommended), when a data change (for example migration from a Web server to a new host, with a new IP address) to lower the TTL in advance , so that the transition is painless, then back up afterwards.
So, the term "propagation" is bad, because it is reminiscent of an update model that is not that of the DNS. It is better to use another term. There is no standard so I adopt a term proposed by Michel Py: "rejuvenation".
It exists in the dictionary and sounds good. I wish that we say from now on things like "The AFNIC has just modified .fr, it is now necessary to wait for the rejuvenation of the data. "
1. rejuvenation process
With a DNS debugging tool like dig , we can see this rejuvenation process: % dig A www.cfeditions.com ... ;; ANSWER SECTION: www.cfeditions.com. 43 IN A 178.33.202.53 The answer was found and the remaining time to live in the cache is 43 seconds (the second field). If we start again two minutes later, this time will have been exceeded and the resolver will have to rejuvenate the data: % dig A www.cfeditions.com ... ;; ANSWER SECTION: www.cfeditions.com. 120 IN A 178.33.202.53 And here we go again for a duration of 120 seconds, that determined by the authoritative server. Let's check by asking him directly: % dig @ ns6.gandi.net A www.cfeditions.com ... ;; ANSWER SECTION: www.cfeditions.com. 120 IN A 178.33.202.53
This duration is extremely low (much too much) but it was to illustrate the fact that it was under the exclusive command of the domain manager. In the past, typical TTLs were 24 to 48 hours, hence the legend "DNS delay is 24 to 48 hours". Today, the most common durations are 4 to 12 hours although some abuse and indicate ridiculously short durations.
So, of course, the DNS experts among my readers will say that it's more complicated than that. There are other causes for update delays, such as the reactivity of the DNS host when modifying an area via the control panel, the reactivity of the registry when it is sent changes (there was a time when it It was common for TLDs to change only once or twice a day), synchronization between authoritative servers (usually almost instantaneous since RFC 1996 but there may be issues), and so on. That said, the longest delays are usually due to the caches of the resolvers.
2. other words
Other words to propose instead? I heard "update" but I find it less beautiful.
" update " ? "Cache expiration" (too technical and not literary enough)? "Rebiscoulation" (the verb "rébiscouler" is used in the South-West of France in the sense of "to go back, to requin")? "Regain"? "Refresh" (too much risk of confusion with the Refresh field of the SOA record , which has a different meaning)? "Reviviscence" (which can also be called "reviviscence")?
An interesting tool to look at the coolness of DNS information by asking for open DNS resolvers (accessible to all) is http://www.migrationdns.com/ . Another, which offers several interesting possibilities (ask open resolvers, ask authoritative servers, etc.) is http://www.preshweb.co.uk/cgi-bin/dns-propagation-tracker.pl . Finally, http://www.whatsmydns.net/ mention http://www.whatsmydns.net/ .
And finally, a good summary by Wesley George during an IETF meeting: "if you need to pull it, put it in DNS, if you need to push it, put it in BGP".
PDF version of this page (but you can also print from your browser, there is a style sheet provided for this)
XML source of this page (this page is distributed under the terms of the GFDL license)
If you like, you can pay with Flattr Flattr this or with Bitcoin : address 1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax (or see the QR code ). For any comments on this blog, contact Stéphane Bortzmeyer <stephane+blog@bortzmeyer.org> . I am Crocker's rules so no need for diplomacy. This blog is strictly personal and the opinions expressed here are therefore binding only on me, and in particular not my present employer or my past employers or my prospective future employers.