Thanks a lot Jorge. Am gonna go with option 2, and remove ns3 three days before cut-over, to be even safer.
Thanks a lot, Mohamed. On Sun, Jun 15, 2014 at 3:45 PM, Jorge Fábregas <[email protected]> wrote: > On 06/15/2014 01:18 PM, Mohamed Lrhazi wrote: > > We need to change our ns3.dom.ain IP address, part of data center move... > > > > I see that the ip address of the NS servers is to be updated at the > > registrar, in addition to in our own zone data.... > > > > Where, or where else, does that record live? Can its TTL be lowered in > all > > those places? What are the gotcha's? > > Hi Mohamed, > > You just lower the TTL on your zone and all the resolvers out there will > reflect that (as opposed to the TTL at your parent). It's your TTL the > one that prevails (since you're the ultimate authority for your zone). > That's at least in theory (and what I've seen so far). > > > Also, been thinking that since we cant have both old and new IPs up at > the > > same time, maybe it might be simple to just go ahead and delete ns3 from > > the registrar database, and just add it again way later, after our data > > center move... Would that be a better solution in this case? > > I see three possible ways: > > # SCENARIO 1 # > > a) change the ip of NS3's "A" record to that of your NS2. Do the same > at your parent. > b) lower the TTL of the "A" record on your zone to, say, 5 minutes > c) wait 24 hours (reason on my last paragraph...) > > Migration.... > > d) once new server is ready change back the "A" record for NS3 at your > zone & parent > e) increase TTL accordingly > > # SCENARIO 2 # > > This is the one you mentioned: > > a) delete reference for ns3 in your zone & at your parent > b) wait 24 hours (reason on my last paragraph...) > c) shut down service/server... > > Migration... > > d) start service > e) include new NS3 record in your zone & parent (don't forget > corresponding PTR) > > # SCENARIO 3 # > > Ask the network guys to redirect DNS packets coming to NS3 to any of > your other nameservers. If all three nameserves are geographically > dispersed this might get complicated. > > --- > > We recently performed the first scenario and everything worked pretty > good. However, remember that there could be some resolvers out there > that might not honor your TTL and may cache, longer than necessary, your > DNS records (causing hits against it when it no longer exists) so, for > scenario #1 & #2, even after lowering the TTL to 5 minutes, I'd wait 24 > hours before starting the migration ( just to be on the safe side). > > > HTH, > Jorge > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs >
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
