Logistics for a bind-DNS newbie

[Kevin Darcy]

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