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?

  • 2
    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, 2012 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, 2013 at 17:09
  • 4
    @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, 2013 at 18:06
  • 2
    @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. Jan 31, 2013 at 22:14
  • 1
    @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, 2013 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.

  • 11
    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. Jan 31, 2013 at 22:10
  • 11
    @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.) Feb 1, 2013 at 16:47
  • 3
    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, 2013 at 10:59
  • About TTL honouring: the TTL is the maximum value to keep things in cache, a caching resolver is free to ditch the data before it. So they can lower it if they want. However it is true that they should not increase it, that is a violation of the protocol. But for the people putting like 1 second in the TTL some caches defend themselves by just not honouring that and clamping at like 5 minutes instead. Aug 18, 2018 at 15:47
  • 1
    Love the strong language in this pre-PC-world post! Ah, the good old times... Jun 9, 2020 at 8:40

You must log in to answer this question.