How to migrate a BIND DNS server to new hardware?

I'd always avoid using Webmin. If it's a regularly-configured Ubuntu BIND server, it should be sufficient to install the bind9 package on the new machines, copy the contents of /etc/bind to the new machines, then adjust the settings on each machine to talk to the new one, change the delegations (or IP addresses, if appropriate) and get on with life. For a seamless (zero-downtime) migration, do one machine at a time.

Firstly make a copy of your /etc/bind directory

sudo tar czvf bind.tgz /etc/bind

If not copy your bind archive remotely to your new server.

scp bind.tgz user@target:~/

Connect to your new server

ssh user@target

Install bind9 via apt

sudo apt-get install bind9

You can also grab the latest source from the isc web site (https://www.isc.org/downloadables/11)

Untar your archive into /etc/bind directory

sudo tar xzvf bind.tgz -C /etc/bind

Do the changes that you need into your config files, may be into your zones files ...

and lastly, start bind

sudo /etc/init.d/bind9 start

Since I'm right in the middle of migrating our servers to new hardware, I'll toss into the ring for this one.

First, if at all possible, do not expose your master server (the one where all the changes should occur) to the internet. Even if it means building a small VM session to host a hidden master, it makes moving stuff around and keeping it secure far easier.

As an example, here's part of my bind layout (in /etc/bind):

-rw-r-----  1 root bind 2.6K 2009-08-07 10:41 named.conf
-rw-r-----  1 root bind 112K 2009-07-24 07:54 named.external.conf
-rw-r-----  1 root bind 112K 2009-07-24 07:53 named.internal.conf
-rw-r-----  1 root bind  792 2009-07-01 10:28 named.logging.conf
-rw-r-----  1 root bind  834 2009-07-01 10:28 named.options.conf
-rw-r-----  1 root bind  373 2009-07-01 10:28 rndc.conf
-rw-r-----  1 root bind  131 2009-07-01 10:28 rndc.key

named.conf contains my basic settings, and then includes the other files with:

include "/etc/bind/named.logging.conf";
include "/etc/bind/named.options.conf";

include "/etc/bind/rndc.key";

Build your new servers and point them at the old master server:

zone "adnszone.com" {
        type slave;
        masters ( your.master.server.ip; etc.etc.etc.etc; }; 
        file "internal/adnszone.com";
};

Let them populate.

Once the new master server (hopefully hidden) is ready, you can very easily go in and modify the particular conf file to point to the new master and viola!

womble's answer is good.

also, if at all possible try to avoid having to redelegate your name-servers (i.e. try to end up with the new servers having the same IP addresses as the old).

if the new servers are on the same IP subnet as the old, no problem - just set them up using temporary IP addresses and swap them for the real IPs when they're configured. change the IP on the old server, and change the IP on the new server (you may need to clear the arp cache on your router or switches).

if something goes wrong with the new setup, you can quickly and easily revert just by swapping the IP addresses back again....by contrast, reverting after you have re-delegated is nowhere near as easy or as quick because you can't change that yourself, you have to submit a request to your DNS registrar (which may take 5 minutes or it may take a day, or even weeks depending on how clued up they are).

this may sound overly paranoid, but i've learnt over the years that leaving yourself a way to revert any change is always a good idea...quite often, making changes will reveal hidden/undocumented dependancies on the way things used to be set up before you changed them. and it doesn't matter who made the undocumented dependancy or how wrong it was - you changed the config, so it's your fault.

if the new servers are on a different subnet, you have no choice but to re-delegate.

Make sure that the RR files are in /etc/bind as well (Fed/Cent/RH they are in /var/some/where/) for the fastest switch over.

Or, once the new systems are up, make them secondary's of the old systems, have them transfer the RR's over, then swap the new ones to primary's. This also works if the primarys are encrypting the RR record files.