Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I got a job to migrate 2x BIND DNS servers to new hardware.

Apparently they are using 3U prehistoric servers running Ubuntu server 8.04.
I'll get to install 2x 1U servers with Ubuntu server 9.04.

How can I transfer DNS settings, DNS cache? What folders/configuration files do I need to transfer?

Will I achieve anything if I use Webmin > Backup configuration > BIND DNS server or should I avoid using Webmin?

share|improve this question
add comment

5 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
+1 I'm just in the progress of migrating are bind server to a new one, just copying the config and make the tweeks should do the trick. –  Mark Davidson Aug 7 '09 at 10:06
    
+1 for avoiding Webmin. –  John Gardeniers Aug 7 '09 at 10:24
    
I'd probably go one further and review the contents of BIND's config so that it's clean and Webmin-free on the new machine. –  Dan Carley Aug 7 '09 at 10:46
add comment

Firstly make a copy of your /etc/bind directory

sudo tar czvf /etc/bind bind.tgz
Note that if your Bind run in a jail, you have to build it again by creating jail, the hierarchy, the devices ...

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

share|improve this answer
add comment

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!

share|improve this answer
2  
populating a new master by first making it a slave is a bad idea - it loses the original line order and formatting of the zone files, including all comments. use rsync or scp or some other method of actually copying the files from the old server to the new (even ftp will do) –  cas Aug 8 '09 at 0:14
    
true, but that only applies on the master anyway, comments will never propagate to the slaves. So, for interesting records, I use a TXT record and append info. to the front of the record: blah.domain.com A 1.2.3.4 info.blah.domain.com TXT "main blah server for Toledo" –  Greeblesnort Aug 10 '09 at 21:30
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.