Logistics for a bind-DNS newbie

papi papi.antoniadis at gmail.com
Wed Nov 16 01:39:31 UTC 2005

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?


More information about the bind-users mailing list