2000-08-01-10:50:58 Ben Beuchler:
> Sometime in the near future we will be a djbdns shop. It will
> take some arm twisting of the other admins, but it will happen.
That's good. You'll be glad.
I'll tell you how I made the transition, not that this is the only
way or anything, but it worked really well for me.
I started by setting it up on my own workstation. First I ran myself
a dnscache. Then I scripted some stuff (which I've published, it's
my little packet of helper scripts, available from dnscache.org) to
make it easy for me to set up "secondaries", tinydns servers that
poll other servers via zone xfer to get the authoritative data that
they'll serve. I set up one of them on my workstation, polling from
my company's authoritative nameserver to pick up the company zones.
As my own workstation doesn't have a static IP addr, I ended up
putting my dnscache on 127.0.0.1, and my tinydns on 127.0.0.2. Then
I told my dnscache to reference my tinydns for the zones that
tinydns was tracking. Now I had a standalone nameservice of my own,
with tinydns pumping out the zones our company is authoritative for,
and could experiment and learn how it worked.
My next step was to start rolling out dnscache installs. I started
with servers; any box that wants to be able to do DNS lookups, and
that can run dnscache, I tried to install it. I got the major
servers anyway. That bought an instant security and performance
improvement, with no visible changes; this was just switching server
at a time to using 127.0.0.1 in /etc/resolv.conf and running a local
dnscache. That went perfectly, no problems at all.
Then I got the company's secondary running tinydns, with my
mirroring scripts pulling via zone xfer from our primary. That
worked fine too, and enabled the other SAs to see what a working
tinydns install looks like, and to look over the config and satisfy
themselves that they'd find it maintainable and supportable. That
was also painless, since secondaries normally don't get manually
maintained, and since I'd already tested out the scripting that
brought it up accurately and correctly the first time.
Finally we set up a new tinydns server to be the authoritative
master for our zones. We had it mirroring via zone xfers, with my
scripts, from our primary. We then had the registrars switch the
zones to the new server. Then a week or so later, when we were sure
nobody would still be thinking about the old one, we simply switched
it off, and started hand-maintaining the new tinydns master. In
between those two, when the new primary was up and mirroring
properly and before switching off the old BIND master, we switched
the secondary so it got its updates via rsync-over-ssh from the new
tinydns primary rather than via zone xfer from the old one.
It may seem kinda roundabout, but I found this a low-stress,
painless way to ease on into the new way of doing things, and I
haven't been lynched by my fellow SAs yet. I did take some care to
talk through what I wanted to do, and why, and what visible changes
would appear at each step, and how they'd need to administer things,
so everybody felt informed and felt like they had a chance to object
if I was about to gore their ox somehow.
-Bennett
PGP signature
