switching entire DNS system to new servers and IP addresses

Mik J mikydevel at yahoo.fr
Sat Feb 25 08:47:18 UTC 2017


Hello,

>From my personnal experience I would add
* Check if you have monitoring in place, you might want to monitor all types of queries and error messages.
* Since you have external and internal DNS then there might be firewalls between them, check if the flows are opened and prepare a test plan with many cases long queries, tcp etc.

* Don't do everything at once, do external DNS first, then internal DNS, then DHCP

* Check if your bind version and Infoblox bind versions are roughly the same, if your bind version is really old it might tolerate things that newer bind version won't

* Take care about your ACLs, you might want to do some cleaning and you also might want to make sure you don't have any security holes
* If you delegate zones or zones are delegated to you or another university is slave for your zones or some of you zones is slave of other servers that don't belong to you, check with them to update firewalls rules and ACLs

* Make sure your new IP adresses are routed :D
* Prepare your rollback



I would really pay attention to the cleaning and everything that goes around this swap (my points above) because in my opinion failure is often because of these things more than upgrading bind or changing vendor



Le Vendredi 24 février 2017 11h57, Phil Mayers <p.mayers at imperial.ac.uk> a écrit :
On 23/02/17 20:21, Mitchell Kuch wrote:

> In practice, we have encountered caching resolvers that provide
> non-decrementing TTL values to downstream resolvers and clients. Even

That is a depressingly common residential ISP trick :o(

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


More information about the bind-users mailing list