Logistics for a bind-DNS newbie

Kevin Darcy kcd at daimlerchrysler.com
Wed Nov 16 20:47:29 UTC 2005

papi wrote:

>On Tue, 15 Nov 2005 19:10:19 -0500, Kevin Darcy wrote:
>>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
>Thanks for the quick reply, Kevin. From what you are saying here (the
>gotchas), it looks like I may be better off building an "identical"
>(as in "zone files equivalency between W2K and bind") bind server,
>off-line, with the same IP address and name as the W2K I was going to
>remove, then simply swap them. If this sounds OK - are there any obvious
>gotchas with this approach, that you could think of?
Yeah, that should work too. It shouldn't be too disruptive as long as 
you can minimize the downtime of switching the IPs around.

                                                            - Kevin

More information about the bind-users mailing list