Logistics for a bind-DNS newbie

Kevin Darcy kcd at daimlerchrysler.com
Wed Nov 16 00:10:19 UTC 2005

Papi wrote:

>I have a kind request for the DNS/bind gurus out there, in regards to
>something I would like to try, but not sure on how to do it, without
>screwing something up:
>- existing setup: dual DNS setup, with a master on my premises, set up
>years back on a W2K machine, which is SOA for mutiple domains registered
>to us, and a secondary at the ISP, which is supposed to pull the info from
>the master
>- desired setup: I would like to have a two-step process, at the end of
>which I would get rid of the W2K DNS. I am thinking of setting up another
>bind-based DNS server (1st question - how to integrate it, w/out breaking
>things) as a third one for all my domains/zones, then remove the W2K one,
>while (2nd question - how?!?) making the new bind-based server take its
>place in the scheme of feeding the ISP server with the info (i.e. the
>provider pulling info from the new one)
>I would appreciate any pointers to docs, or advice in regards to steps to
>achieve the above (or if anything appears to be flawed in the logic).
Put simply, make the BIND box a slave, then publish it as a nameserver 
for the zones in question (by "publish", I mean there would be NS 
records pointing to it in both the delegation set and the "apex" of the 
zone), then have your ISP add the IP of the BIND box to their "masters" 
list (or the equivalent, if they're not running BIND), then you can 
switch the master/slave roles between the W2K box and the BIND box at 
your leisure. Sometime after that, sundown the W2K box (i.e. remove the 
NS records, remove the IP from your ISP's "masters" clause, optionally, 
turn the box off, burn it, throw it out a 3rd-floor window, whatever).

Changing NS records at the apex of your zone is of course rather 
trivial, but changing delegation NS records will most likely (depending 
on where in the namespace your domains are located) require interaction 
with one or more domain registrars, and whatever tools/processes they 
provide for such things. It's hard to generalize, since registrars vary 
greatly in this regard.

The most likely glitch you might run into is that the MNAME field of the 
SOA record is used by the NOTIFY and Dynamic Update extensions to the 
DNS protocol. So if you depend on either of those, you might want to 
change SOA.MNAME at the same time as you switch the master and slave 
roles. Beyond that, just make sure your allow-transfer's (if you use 
them) are updated appropriately during the migration process, that your 
ISP actually has connectivity to your new box, firewall rules are 
updated if applicable, i.e. basic connectivity/infrastructure stuff.

                                                            - Kevin

More information about the bind-users mailing list