2

We have just changed our DNS record to point to a new server running IIS. How long will it take until the address is changed to the new server? Some people can still see the old server and some can see the new.

I have flushed the dns on my pc and it seems to be fine although it doesn't with another of my pcs.

Thanks

StrattonL
  • 143
  • 6
  • http://serverfault.com/questions/82251/why-is-it-called-dns-propagation http://serverfault.com/questions/54758/how-long-does-it-take-for-dns-to-update-new-records-strange-dns-behaviour http://serverfault.com/questions/20123/how-long-will-a-dns-change-take http://serverfault.com/questions/129544/how-does-dns-get-stuck – Zoredache May 16 '10 at 07:17

2 Answers2

2

It depends entirely on the TTLs for the domain or individual resource record, and varies depending on when the record was fetched (and cached) by each distinct resolver throughout the Internet.

You can find out the TTL for your local resolver with dig:

$ dig serverfault.com a | grep serverfault | grep -v '\;'

serverfault.com. 44257 IN A 69.59.196.212

So for serverfault.com, my local resolver will hold onto this record for 44257 more seconds. To find the true TTL, we need to first identify the authoritative nameservers.

$ dig serverfault.com ns | grep NS | grep -v '\;'

serverfault.com. 86392 IN NS ns4.p19.dynect.net.

serverfault.com. 86392 IN NS ns1.p19.dynect.net.

serverfault.com. 86392 IN NS ns2.p19.dynect.net.

serverfault.com. 86392 IN NS ns3.p19.dynect.net.

Then we can query one of them directly for the TTL.

$ dig @204.13.250.19 serverfault.com | grep serverfault | grep -v '\;' | grep-v NS

serverfault.com. 86400 IN A 69.59.196.212

In this case, the resource record for "serverfault.com" is 86400 seconds (1 day).

obfuscurity
  • 761
  • 3
  • 7
0

This is one of those questions that keeps popping up but under different headings, so it's hard to spot the duplicates.

Let me start be correcting your terminology a little. Based on the context of the question you should be asking about propagation, not replication, as the latter is between DNS peers (master & slaves).

There are a number of factors that determine propagation delay. On the surface it would appear to be a simple matter of using the TTL time. The normal approach when you know an address is to change is to reduce the TTL to a short period, say an hour, prior to making the actual change. If the TTL is set to less than an hour you can pretty much expect most systems to ignore it and use an hour anyway.

Unfortunately, an ever increasing number of systems are completely ignoring the TTL and are supplying cached information that may be out of date. There is absolutely nothing you can do about this, unless you are in control of those systems.

Even the local computer's cache can be a problem, as the operating systems may not even check the TTL, let alone honour it, so may be using incorrect information, even if the upstream DNS server has the correct information.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108