26

Possible Duplicate:
How long does it take for an A record to propagate?

I recently changed nameservers and it has been 24 hours since. Some of my visitors are complaining they are still viewing the old site while some are already seeing the new site. Is there any way to speed-up the DNS propagation without updating the hosts file of each of my visitors?

Are there any best practices when it comes to changing nameservers to minimize this problem?

IMB
  • 499
  • 2
  • 7
  • 13

4 Answers4

34

DNS records doesn't propagate in the sense that they aren't "pushed" from your server to other resolvers. What actually happens is that when other DNS servers look up your domain, they cache the record for X seconds so that they don't have to do another lookup for subsequent requests. X seconds should be determined by the TTL value on the record when it was retrieved from your name server. If you've already changed the address there's nothing you can do but sit and wait. If you had planned this in advance, you could have lowered the TTL value.

Some larger DNS resolvers cache longer than the TTL, which is a violation of the relevant RFCs (but they don't care). If you can track this issue down to a few name servers, you can email the operators and ask them to invalidate the cache for your zone so that they'll stop using the cached (old) record.

Honestly, though, unless this goes on for an extended period of time, it's probably just as well that you sit tight and wait and plan a better migration for next time, since the damage is already done.

MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • Thanks. So you mean setting the TTL low is just a best bet since some ISPs don't really follow it, and that in reality, it's pretty much a sit and wait game regardless of my preparations? – IMB Nov 08 '11 at 18:46
  • 1
    @IMB Yes. Setting a low TTL prior to an IP/server migration is a good idea, but not a guarantee. If you're swapping servers, using database replication and syncing content via rsync is usually a pretty good way to make this seamless to the end user. If you care about redundancy and availability, you should probably be doing these things anyway. You'd just add the new nodes to the replication scheme and let it sit there long enough for the non-compliant resolvers to roll their cache over (1-2 weeks usually). – MDMarra Nov 08 '11 at 18:50
  • If I ask my users to use Google's public DNS, would this help them? Because right now I am on Google's public DNS and it's pointing to the updated nameserver. I am not sure though if it's working for all who uses Google's. – IMB Nov 09 '11 at 09:59
  • 1
    You can ask, but if any are businesses the answer will probably be no and it could make you look bad. I'd just wait it out and do better next time. – MDMarra Nov 09 '11 at 11:40
4

Apart from ensuring that you pre-publish with a low TTL as suggested by the other answers, also ensure that your old name servers are either a) turned off, or b) serving the new zone file.

The reasons why are explained in my answer to this question, but the short version is - some resolvers will continue to query the old name servers, and won't notice that the parent zone has changed.

Alnitak
  • 20,901
  • 3
  • 48
  • 81
  • It doesn't sound like he changed name servers. I could be wrong, but it sounds like he is just updating A records. – MDMarra Nov 09 '11 at 03:10
  • I changed nameservers like this: ns1.xxx.com to ns1.yyy.com – IMB Nov 09 '11 at 10:00
  • @IMB so make sure the old name servers have the new NS records in their zone file - i.e. make sure _every_ name server is consistent. – Alnitak Nov 09 '11 at 10:20
  • @Alnitak You mean update the IP address of xxx and yyy so they point to the same IP right? The problem is the other nameserver is on a shared host (ns1.dreamhost.com) so I am unable to edit the IP. – IMB Nov 09 '11 at 10:30
  • @IMB no, I mean get your old DNS host to change your zone file to have the same contents as your new one. – Alnitak Nov 09 '11 at 11:13
2

Are there any best practices when it comes to changing nameservers to minimize this problem?

As MarkM already said - set default TTL to small value. Best practice is "Think forward", i.e - set small TTL before time of change, wait while old records will expire, after it change RR data.

Lazy Badger
  • 3,067
  • 14
  • 13
2

As everybody already stated, but in other words:

TTLs propagate as slow as any other record. So you can't fix DNS propagation by reducing the TTL. It is meant to prevent long caching records. It doesn't guarantee fast propagation.

mailq
  • 16,882
  • 2
  • 36
  • 66