<div dir="ltr">Thanks a lot Jorge. Am gonna go with option 2, and remove ns3 three days before cut-over, to be even safer.<div><br></div><div>Thanks a lot,</div><div>Mohamed.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Sun, Jun 15, 2014 at 3:45 PM, Jorge Fábregas <span dir="ltr"><<a href="mailto:jorge.fabregas@gmail.com" target="_blank">jorge.fabregas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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