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