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.may...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
