Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is a Canonical Question about DNS Propagation

How long does it take for an the various types of records to propagate?
Do some propagate faster than others?
Why does it take time for DNS records to propagate and how does it work?

share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

migrated from stackoverflow.com Mar 23 '10 at 13:38

This question came from our site for professional and enthusiast programmers.

1  
Note: Historically there was a notable and significant difference in the time it takes to update different types of records (depending on who kept them and such). This is no longer the case today. –  Chris S Aug 6 '12 at 18:07
4  
When ppl use word "propagate" for DNS it clearly shows they don't know what DNS is and how it works. Let's hope documentation would "propagate" fast enough (crossing fingers). –  poige Jan 23 '13 at 17:09
3  
@tonygil Please see Poige's comment. There's no such thing as dns propagation. Also, ISPs don't control the root servers. If those ISPs' DNS servers are caching longer than the TTL of the record, then they're violating RFC. You seem to have several misunderstandings with how DNS works; but RFC violations will usually break the way it's supposed to work. This has nothing to do with the US or Europe. –  Chris S Jan 23 '13 at 18:06
1  
@tonygil: The "cyberpolice" to "make" them update is all of the sysadmins, network admins, etc, exerting social pressure on bad actors. The Internet works because we all agree that it should. The best interests of our users, networks, etc, are in the manifest "best interest" of the Internet. re: "users aren't technogurus" - This is a site for professional systems administrators and not end users. Frankly, I expect sysadmins to be a sort of "technoguru" (to use your terminology). Sysadmins are, by occupation, supposed to care how this stuff works. –  Evan Anderson Jan 31 '13 at 22:14
    
@EvanAnderson i completely agree that pressure makes for change. on the other hand, the reality is that lazy or incompetent sysadmins are out there in hordes. and the farther you move from the us and europe, the more frequent they become. your expectations are fine 4 US but they are not be feasible in most parts of the real world, where unprepared sysadmins are the rule. so, while you expect everything to be fine, you shoulkd deal with the real world, where they are NOT. anyway, made my point, you made yours. let us agree to disagree. –  tony gil Feb 1 '13 at 15:41

1 Answer 1

"DNS propagation" isn't a real phenomenon, per se. Rather, it is the manifest effect of the caching functionality specified in the DNS protocol. Saying that changes "propagate" between DNS servers is a convenient falsehood that's, arguably, easier to explain to non-technical users than describing all of the details of the DNS protocol. It's not really how the protocol works, though.

Recursive DNS servers make queries on behalf of clients. Recursive DNS servers, typically run by ISPs or IT departments, are used by client computers to resolve names of Internet resources. Recursive DNS servers cache the results of queries they make to improve efficiency. Queries for already-cached information can be answered without making any additional queries. The duration, in seconds, that a result is cached is supposed to be based on a configurable value called the Time To Live (TTL). This value is specified by the authoritative DNS server for the record queried.

There is no one answer to all the questions being asked because DNS is a distributed protocol. The behavior of DNS depends on the configuration of the authoritative DNS server for a given record, the configuration of recursive DNS servers making queries on behalf of client computers, and DNS caching functionality built-in to the client computers' operating systems.

It's good practice to specify a TTL value short enough to accommodate neecssary day-to-day changes to DNS records, but long enough so to create a "win" in caching (i.e. not so short as to age-out of cache too quickly to provide any efficiency improvement). Employing a balanced strategy with TTL values results in a "win" for everyone. It reduces both the load and bandwidth utilization for the authoritative DNS servers for a given domain, the root servers, and the TLD servers. It reduces the upstream bandwidth utilization for the operator of the recursive DNS server. It results in quicker query responses for client computers.

As a DNS record's TTL is set lower load and bandwidth utilization on the authoritative DNS servers will increase because recursive DNS servers will not be able to cache the result for a long duration. As a record's TTL is higher changes to records will not appear to "take effect" quickly because client computers will continue to receive cached results stored on their recursive DNS servers. Setting the optimal TTL comes down to a balancing act between utilization and ability to change records quickly and see those changes reflected on clients.

It is worth noting that some ISPs are abusive and ignore the TTL values specified by the authoritative DNS servers (substituting their own administrative override, which is a violation of RFC). There's nothing to be done about this, from a technical perspective. If the operators of abusive DNS servers can be located complaints to their systems administrators might result in their implementing best practices (arguably what amounts to common sense for any network engineer familiar with DNS). This particular type of abuse isn't a technical problem.

If everybody "plays by the rules" changes to DNS records can "take effect" very quickly. In the case of changing the IP address assigned to an "A" record, for example, an exponential backoff of the TTL value would be performed, leading up to the time the change will be made. The TTL might start at 1 day, for example, and be decreased to 12 hours for a 24 hour period, then 6 hours for a 12 hour period, 3 hours for a 6 hour period, etc, down to some suitably small interval. Once the TTL has been backed-off the record can be changed and the TTL brought back up to the desired value for day-to-day operations. (It is not necessary to use an exponential backoff, however this strategy minimizes the time the record will have a low TTL and decreases load on the authoritative DNS server.)

After making a DNS record change logs should be monitored for access attempts being made as a result of the old DNS record. In the example of changing an "A" record to refer to a new IP address a server should remain present at the old IP address to handle access attempts resulting from client computers still using the old "A" record. Once access attempts based on the old record have reached an acceptably low level the old IP address can be disused. If the requests related to an old record are not abating quickly it is possible that (as described above) a recursive DNS server is ignoring the authoritative TTL. Knowing the source IP address of an access attempt, however, does not provide direct information as to the recursive DNS server responsible for supplying an old record. If the IP addresses of errant access attempts are all related to a single ISP it may be possible to locate the offending DNS server and contact its operator.

Personally, I've seen changes "take effect" immediately, in a few hours, and in some cases with a particular brain-damaged ISP, after several days. Doing a backoff of your TTL and being mindful of how the process works will increase your changes for success, but you can't ever be sure what some well-meaning idiot might be doing with their recursive DNS servers.

share|improve this answer
6  
This isn't an answer about "OpenDNS"-- it's an answer about DNS. Any recursive DNS provider could implement whatever interfaces they wanted to allow cache purges, etc. We're talking about DNS-- not about vendor APIs. Insofar as your edits: I'm standing by the phrase "brain damaged" as being a phrase long-used in hacker culture, and I'm using it in that context (see the Jargon File, Steven Levy's "Hackers", etc). As far as "idiotic" goes I think it's reasonably established that, outside of legal codes, this is a colloquial term for actions that are of an incompetent nature. I stand by it, too. –  Evan Anderson Jan 31 '13 at 22:10
7  
@tonygil - OpenDNS isn't DNS. It's just a service somebody offers. What if FooDNS opens tomorrow and has some exciting new cache clearing API? Should my answer include that, too? Where does it stop? This is degenerating into madness. re: civil rights - I'm not an employer or government entity denying civil rights to a member of a protected class. Sure-- go ahead and see if you can find somebody who wants to prosecute me. They can reach me via mail at P.O. Box 852, Troy, OH. (866) 569-9799, x801 forwards to my cell phone 24x7. (That's some good detective work there looking at my profile, BTW.) –  Evan Anderson Feb 1 '13 at 16:47
1  
u see, u said that peer pressure brings change. that was what i did. brought to ur attention that i do not agree with ur use of "idiot" and "brain-damaged" because they r offensive and derogatory. the fact that someone uses it profusely (i.e. hackers) does not make it right. the kkk used the n-word profusely. pls respect those of us who care for mentally impaired ppl. i understand that u incorporate the terms metaphorically in ur colorful style, but believe me: they r offensive and unnecessary. –  tony gil Feb 2 '13 at 10:59

protected by Chris S Aug 6 '12 at 17:52

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?