37

I am migrating our app from a cloud server at Rackspace t a dedicated server.

I want to bring the application down for ~5 minutes to copy the data from the cloud server to the dedicated server, so I don't want requests going to the old server after I have copied the data.

I want to point our DNS record at the new server, but the TTL was set to 24 hours. I have changed it to 300 seconds. Do I need to wait the 24 hours before updating the ip that domain points to / copying the data?

Improve this question
2
  • 11
    BTW even if you do wait for the TTL I strongly reccomend you edit the configuration on the old server to make sure no more updates will be accepted there. Not all DNS resolvers actually follow the standards.
    – Peter Green
    May 2, 2016 at 22:59
  • 5
    What I did when moving a web-application from one hosting provider to another was to use an ssh port forwarding to get any visitors still using the old IP directed to the new server.
    – kasperd
    May 3, 2016 at 11:03

5 Answers 5

Reset to default
60

Anyone who has a cached copy of the domain record will not bother updating it for 24 hours, so yes if your intent is to have at most a 5 minute window of unavailability you should wait until all of the outstanding caches have updated to live no more than 5 minutes.

Improve this answer
6
  • 24
    ... it for 24 hours since they last cached it. This could be anything from 1 to 86399 seconds.
    – user9517
    May 2, 2016 at 22:36
  • 7
    @Iain You have to assume the worst, since any or all of them could have just cached it just before the change.
    – Barmar
    May 3, 2016 at 18:00
  • 7
    @Barmar Don't assume anything. Plenty of ISPs just plain ignore TTL.
    – user9517
    May 3, 2016 at 21:16
  • 15
    @Iain I used to work for Akamai, a CDN that makes heavy use of short TTLs (like 60 seconds) for load balancing. I recall that we did a study and found that most ISPs did obey our TTLs.
    – Barmar
    May 3, 2016 at 21:34
  • 2
    I work for a webhosting company, our experience is that low TTLs are more likely to be ignored than higher.
    – Henrik supports the community
    May 4, 2016 at 23:56
39

It's (potentially) even worse than that -- you have to wait 24 hours after all of your authoritative servers have updated. The normal way for updates to happen is that you make a change to the zone on the primary server, and then each of the secondaries transfer the new zone data the next time they happen to check in with the primary. The check in frequency is controlled by the refresh interval in the zone's SOA record. Thus, in the worst case you'd have to wait the zone's refresh interval + the record's TTL.

You may also have to wait this long for the actual record changes. A 5-minute TTL won't do a lot of good if the secondaries only refresh every 6 hours. So you probably want to decrease the refresh interval on the zone as well for the period you want to be able to make quick changes.

Mind you, this may not apply to your setup. If you have a system that updates all authoritative servers together, this is not a problem (and I'm not familiar with Rackspace's DNS setup). But I'd recommend querying all of your authoritative servers individually (dig server.example.com @secondaryserver.example.com) to make sure they have the new TTL before starting your 24-hour countdown.

Improve this answer
6
  • 1
    This should be the accepted answer.
    – dotancohen
    May 3, 2016 at 9:08
  • 4
    You seem to be ignoring the DNS Notify protocol, which tells slave servers to refresh shortly after the master is updated. Most DNS servers use this feature.
    – Barmar
    May 3, 2016 at 18:01
  • @Barmar: That's true, but at the same time the master could take a while to update depending on the provider. (For example, some providers only rebuild zones from the database every 5 or 15 minutes, although modern ones do it instantly.)
    – u1686_grawity
    May 3, 2016 at 18:09
  • 1
    My comment was only addressing the issue of waiting for the Refresh interval, that's mostly obsolete these days. Waiting for the master to update is true, unless you operate your own master. But I think it's unlikely they'll need to deal with the exact time when everything becomes safe to update; 5-15 minutes extra should not make much of a difference. The point of the original question is whether they need to wait a whole day.
    – Barmar
    May 3, 2016 at 18:14
  • 1
    @GordonDavisson: If you don't trust – verify. dig +nssearch example.com is a useful tool for quickly comparing SOAs across all servers; nsdiff shows actual differences.
    – u1686_grawity
    May 5, 2016 at 5:32
23

Yes, you should wait. Even then of course it's not guaranteed that everyone will respect the TTL.

Improve this answer
6
  • 6
    +1 for not everyone obeys the TTL, I've seen stragglers come in a week after making a DNS change. One way I've handled it in the past was to set up a new unique name as an alias on the new site and used a redirect from the old site to redirect users from the old domain to the new ones, like from www.mycompany.com -> newsite.mycompany.com
    – Johnny
    May 2, 2016 at 20:18
  • Yes, but many people will rightfully despise the idea of having to use a new name. Names are brands. Also, this only works for HTTP and for pretty much nothing else.
    – Sven
    May 2, 2016 at 20:20
  • 8
    Another option is to configure the old server as a reverse proxy to the new server. You can then leave that up for a week or so after the switch and turn it off when it has no traffic coming through it.
    – bdsl
    May 2, 2016 at 20:25
  • 1
    People that have well behaving DNS servers that obey the TTL will never see the new domain. And while it "only" works with HTTP(S), I think you'll find that HTTP is a fairly common protocol on the internet. bdsl's suggest of setting up a reverse proxy is even better, but is more work
    – Johnny
    May 2, 2016 at 20:29
  • @Johnny The problem with a new domain is you run the risk of people bookmarking that domain. Unless you plan to leave said new domain accessible forever.
    – Bob
    May 3, 2016 at 13:32
5

Pulling together various comments and answers the complete procedure would be something like.

  1. Make sure you can update your authoratative servers in a timely manner.
  2. Reduce the TTL.
  3. Check all authoratatitive servers have the new ttl.
  4. Wait the old TTL so that cached values with the old TTL are (mostly) eliminated from caches (you can't gaurantee they will be gone from every cache because some caches might ignore the standards).
  5. Put the site on the old server into read-only mode (or if you can't do that replace it with a "we are down for maintinance" page).
  6. Perform the final copy from the old server to the new server (resulting in a read-only site on the new server).
  7. Change the DNS records.
  8. Make sure all authoratative servers have the new DNS records.
  9. Wait for the new ttl (you can skip this step if you don't care about some users being able to contribute to the site and other users not seeing the results of those contributions).
  10. Put the site on the new server into read/write mode.
  11. Put a notice on the old server that it is an outdated read-only copy and that the user likely has broken DNS.
  12. Wait a while for the records to drop out of noncompliant DNS caches.
  13. Decommission the old server.
Improve this answer
5

In addition to the other answers, you can use https://www.whatsmydns.net/ to check how your DNS record is propagating in almost real time. enter image description here

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .