<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><br></div></div><div class="gmail_quote">On Fri, Jul 8, 2016 at 4:01 AM, Dave Warren <span dir="ltr"><<a href="mailto:davew@hireahit.com" target="_blank">davew@hireahit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-07-07 23:46, Mik J wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a bind DNS that is authoritative for many zones and that same system is also forwarding.<br>
I plan to split these two functions on two different systems.<br>
<br>
Have some of you done this task ? Do you have any guidelines or advices ?<br>
<br>
I'm thinking about migrating the forwarding functionality to a new system with a new IP.<br>
This will avoid changing the IP of the authoritative server on the DNS at a higher level.<br>
</blockquote>
<br></span>
Huh. Oddly, I find changing authoritative servers to be quite trivial in a well managed network.<br>
<br>
1) Bring up the new servers.<br>
<br>
2) Update ACLs, firewall rules and scripts/automation as needed, if needed.<br>
<br>
3) Update the zonefiles and upstream zone files. If the primary master moved, make the old primary master a temporary slave, such that you can update slaves at your convenience.<br>
<br>
4) Update any remaining monitoring systems, or client-facing resolvers that forward, stub, or anything else. Consider why you forward, and whether it's useful or you're just doing configuration for the sake of configuration.<br>
<br>
5) Wait 2-4x the length of the TTL, and/or monitor traffic levels.<br>
<br>
6) Pull down the old servers, clean up after them.<br>
<br>
Conversely, changing client facing resolver is a constant pain as there are always "things" that are hardcoded and not using DHCP, depending on the complexity of your environment, possibly thousands of things. Plus there are all the terrible DHCP implementations that renew properly, but fail to update their local configuration until they're restarted. And the users? Some of them hardcode their resolver settings (see #3 above, it's a thing they can configure, therefore some do)<br>
<br>
But maybe that's just me -- Plus, my authoritative servers are relatively simple, other than the master, but renumbering the master without any other changes is also moderately trivial as updating the slaves can (and is) scripted.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Dave Warren<br>
<a href="http://www.hireahit.com/" rel="noreferrer" target="_blank">http://www.hireahit.com/</a><br>
<a href="http://ca.linkedin.com/in/davejwarren" rel="noreferrer" target="_blank">http://ca.linkedin.com/in/davejwarren</a><br>
<br>
<br></font></span></blockquote><div><br></div><div>I agree, it is easier to move the authoritative servers to new addresses, usually.  Just need to update systems that do zone transfers and the ACLs.  Most other things should find the address in the NS record.</div><div><br></div><div>-- </div><div>Bob Harold</div><div> </div></div><br></div></div>