11

I did read a bunch of relevant Q/A here but I am still not sure what the best answer is.

I'm moving a couple of sites from IP address "1.a.b.c" to "2.d.e.f". As of right now in the existing DNS I set all TTL to 300 seconds, and I have a new DNS zone ready to be used (on AWS Route 53), with new nameservers and all TTLs at 60 seconds. So I believe I am ready, from a DNS perspective. Post-move, after a few days I will set TTL to more reasonable numbers at Route 53.

I've warned all my users about the move and I have a defined window of time for the move. I told them that once the move is complete and if 24 hours have gone by and they still see the old (locked) sites, they should reboot their computer to force a local DNS cache flush.

I do not understand how the user's browser (cache) plays a role in this. My own experiments with a local hosts file (Win7) tell me there is something about the browser that is not letting the old IP address go -- I had to go to history->clear everything in order to get the new site location to show up, even after ipconfig /flushdns

(EDIT) - I do not have root access to the old server, so I can't implement the accepted answer to this question.

Question: I really don't want my users to have to deal with that, so is there something I can do to force all the browsers out there to re-cache? And if so, how long do I leave it turned on?

Thanks...

Community
  • 1
C C
  • 413
  • 4
  • 13
  • `My own experiments with a local hosts file (Win7) tell me there is something about the browser that is not letting the old IP address go` Can you provide some info on this? Afaik, browsers do not cache DNS records for more than 1 minute. – Tanmay Dec 28 '16 at 15:40
  • Not sure, but after multiple ipconfig /flushdns and "ctrl-F5" (in Firefox), I was continuing to get a mix of pages from both old site and new site...finally had to clear "everything" and re-start browser. I don't want my users to have to do similar... – C C Dec 28 '16 at 15:44
  • JBTW, the solution in the link you provided can also work if you have root access to the new server. Update the DNS records and forward all traffic from to new server to old one, until DNS has properly propagated. – Tanmay Dec 28 '16 at 15:47
  • thanks...but then I'd have to sync the old back to new (databases, etc) again later, no? – C C Dec 28 '16 at 15:54
  • You will have to sync the database once, just before turning forwarding off. – Tanmay Dec 28 '16 at 16:00
  • Instead of before changing DNS records, you do it after. – Tanmay Dec 28 '16 at 16:01
  • So I have to ask, why are you moving the name servers? – joeqwerty Dec 28 '16 at 16:04
  • Moving from site5 (dns.site5.com) to a cloud service, using AWS nameservers. Need to cancel the site5 account so will lose the site5 nameservers. – C C Dec 28 '16 at 16:58
  • Most browsers do invalidate the cache for the current website with `shift + refresh`! – hookenz Dec 28 '16 at 20:18

4 Answers4

16

No, you can't. The problem is that DNS response can be cached anywhere between user and DNS server and there is no way to invalidate them.

What you can however do - as soon as you have data in sync and your second site is ready, you can reconfigure original server to behave as a proxy and pass all requests to the new location.

This way, you can achieve almost 0s of downtime of your website.

Update

If you don't have root access there are several options:

  • Perform proxying in PHP

  • Configure proxy on the second server (if you have root access there), switch DNS and when you are ready change proxy to webserver

  • This method can be source of problems Have 2 addresses (www.domain.tld and www2.domain.tld). Configure www2 (which is the same as www) and set correct DNS records. Then prepare www version of your site and do the switch of the DNS. Set redirect of all requests on old server to www2 subdomain.

Yarik Dot
  • 1,543
  • 12
  • 26
  • Would you mind expanding a little on this, or with a pointer to an article or Q/A that I could read? I do not have root access to the existing server so I can't directly manipulate IP tables...so maybe there is an alternate way? – C C Dec 28 '16 at 15:27
  • @CC perhaps you have access to replace your application with a HAProxy instance? Or replace your application code with another that purely forwards the request to the new server? – Jason Martin Dec 28 '16 at 15:39
  • @JasonMartin - I have access to .htaccess and the application code. So, yes I could probably grab the requested URL and forward to the new IP address - maybe I should try that? – C C Dec 28 '16 at 15:46
  • @CC that sounds promising then. DNS is a 'eventually consistent' tool, and some DNS servers set floors in their TTL and will ignore your 300s. If you want to avoid any interruption there, a forwarding proxy is the best bet. – Jason Martin Dec 28 '16 at 15:47
4

In theory, setting the domain's TTL to something low and waiting for that change to take place, then changing the IP, should result in a near-transparent migration. After all, that's the whole point of the TTL being configurable.

In practice, people misconfigure things and tools break. That's why you may need to provide instructions to your users to clear their local cache if things don't work right.

You're not doing anything wrong though.

Lightness Races in Orbit
  • 370
  • 2
  • 5
  • 17
  • Should I immediately switch over to the new AWS Route 53 DNS - with the **old** IP address -- then after migration is done simply change the IP address to the new one? -- or just change the DNS to the new one **and** change the IP at the same time? – C C Dec 28 '16 at 20:34
  • 1
    @CC: I'm no network administrator so take this with a pinch of salt (and I'm happy to hear otherwise from ServerFault gurus), but I would personally recommend not changing both at once. Get your DNS sorted out, then perform the IP change and let the new DNS do its job by helping you with that last part. – Lightness Races in Orbit Dec 29 '16 at 00:28
  • 1
    Well I tried an experiment. One site, I changed the DNS hours beforehand, then changed the A record IP address later. Worked perfectly. The other site I changed both at once. It was thrashing between old/new IP address for hours - I finally deleted the AWS Route 53 zone and re-did it the same way as the first site. Worked perfectly. So no pinch of salt needed - you were spot on! – C C Dec 29 '16 at 13:05
1

Inevitably your old address will be cached and used for a long time -- mostly by bots.

How I'd do it:

  • Create an A record, for example www2.yourdomain.com, pointing to new IP. This record should never have been used before; therefore never cached.
  • Redirect queries on old server to www2.yourdomain.com
  • Monitor redirects, and when traffic subsides to an acceptable level, remove old server.
  • And finally once old server is removed, redirect www2.yourdomain.com to www.yourdomain.com.

Be sure to use 301 Permanent redirects. https://en.wikipedia.org/wiki/HTTP_301

ClickLabs
  • 111
  • 1
  • My gut feeling is that he should *not* use 301 for the first round of redirects, but only for the second. Is there any particular reason he should that may only be known to someone with esoteric SEO wisdom? – Random832 Dec 29 '16 at 04:25
  • @Random832 A permanent tells the user-agent to forget about the old url and e.g. update bookmarks to point to the new url (so the next time, they might access the new url directly). There is no harm in redirecting later again (or even back to the original url). A temporary redirect on the other hand tells the user-agent to keep the original url (because the redirect might happen to a different target or not at all next time). Hence with temporary redirects, the redirection monitoring would *never* fall to an "acceptable level". – Hagen von Eitzen Dec 29 '16 at 08:58
  • @HagenvonEitzen It will fall to an acceptable level as browsers stop getting the old server's IP address for www.yourdomain.com, which is a DNS thing and won't be affected by the kind of HTTP redirect used. And "because the redirect might happen ...not at all next time" is therefore precisely true. – Random832 Dec 29 '16 at 16:21
0

Sounds like you're planning on changing your nameservers at the same time? Due to the way nameservers are discovered, they take a lot longer to update than a regular record - often times around 24 hours or longer.

I would highly recommend you update the DNS at your current provider before changing DNS, or change your nameservers 7 days before you change the website IP.

Modern computers and browsers are pretty reliable at obeying TTLs with DNS, but you need to understand the entire chain for the best results.

codatory
  • 113
  • 1
  • 3
  • Thanks, and yes this reflects my comment under Lightness' answer, above. The resolvers did refresh the nameservers pretty quickly - within minutes. The key was to do that first, then wait a few hours before changing the destination IP address. Both at once was bad...very bad. – C C Dec 29 '16 at 21:06