Domain IP change and model concerns

[wanton gust]

The project we've taken over is located on foo.com. We like this address, but not the hosting (A). We want foo.com to point to our replicated project hosted elsewhere (B). We know how to do this, but we are worried that between replicating the project to B and whatever underlying internet mechanisms doing their thing to make foo.com point to B and not A, users will make model updates in A and they will be lost unless we manually copy them.

We kind of need 24/7 availability so we can't just take A down to avoid this. We have access to the files on A, so I was thinking maybe I could rewrite it to forcibly redirect to B? What's the best solution?

[torn star]

Option 1 (easiest):

• Set an extremely low TTL on the DNS record ahead of time (30-60 seconds or so, it should never be less than 30) to make the move as fast as possible, move it during period of least traffic, pull the plug on the old server, and hope for the best.
  Option 2 (requires a lot more work):
• Set up a VPN between old host and new host (if possible, i.e. you have shell access), expose your new DB to the old server, transfer the data, update the project on the old server to use the new DB. It will add latency, but you'll maintain a single source of truth.

VPN is of course optional, but I prefer to expose a DB only to a VPN and not the web at large, even if you have TLS and whatnot.

I don't know how realistic option 1 is for you, but if you don't lose a million in 30 seconds downtime, I'd say f-it and do that. Replace the django app with a maintenance page.

Option 3: use a subdomain (new.foo.com) and send temporary redirects from old app to new.foo.com/same-path/)

Maybe someone has other ideas 🙂

[wanton gust]

I think my boss was concerned that if we did option 1, foo.com would just point at the dead server for a while

he thought it could take days (or just 10 minutes) for the web to point the domain to the new IP

[torn star]

It can, that's why I'd say set the TTL really low (30) a week ahead of time.

[wanton gust]

oh ok

[torn star]

It will give time to all the DNS servers caches to expire.

If my DNS caches foo.com for 2 days, and you set the TTL to 30 seconds tomorrow, it will still keep the old cached value for another day.

2 days from now, it still will fetch the old IP, but cache it only for 30 seconds.

[wanton gust]

but the process of telling the internet that foo.com should lead to B and not A is practically instantaneous?

[torn star]

From my experience, yes.

[wanton gust]

ok cheers, I will show my boss ^^

[torn star]

$ dig SOA theepic.dev
; <<>> DiG 9.18.19 <<>> SOA theepic.dev
;; QUESTION SECTION:
;theepic.dev.                   IN      SOA
;; ANSWER SECTION:
theepic.dev.            3601    IN      SOA     dns1.registrar-servers.com. hostmaster.registrar-servers.com. 1690140522 43200 3600 604800 3601

$ dig @dns1.registrar-servers.com theepic.dev
;; QUESTION SECTION:
;theepic.dev.                   IN      A
;; ANSWER SECTION:
theepic.dev.            300     IN      A       80.240.26.215

You can use dig to find the Start of Authority for your domain, and query it directly to see how quickly it updated.

[wanton gust]

windows scrub here

[torn star]

You can run it on a VPS over SSH.

[wanton gust]

those are mildly over my head too, but I don't think I need to pull this off to get this done 😄

I can get the TTL at least