Questions After a DNS Server Crash

[Mark Andrews]

> 	Last week, we had our primary 9.2.3 bind server crash due to
> massive hardware failure, probably a disk controller, definitely not
> failure of bind or FreeBSD.  Once before, when a slave failed on a
> different subnet than the master, we rather uneventfully brought up
> the master's second Ethernet card on the slave's address and all was
> well until we were able to get a new box that didn't smell of smoke
> and ran again.:-)
> 
> 	This time, it was the master and things went well, but a bit
> rough around the edges so to speak.  In the first place, the
> replacement server normally lives on the same subnet as the cooked
> master.  There appears to be an issue with FreeBSD and probably many
> other UNIXen that won't let you bring up a secondary interface on the
> same network with the same subnet mask.  Even worse, if one uses the
> alias command as in
> 
> alias fxp0 inet 192.168.1.1 netmask 255.255.252.0  for example,
> 
> you get packets that have a 255.255.255.0 subnet mask which won't work
> here.  Someone suggested using a 32-bit mask of 255.255.255.255 and
> that still got a Class C mask.
> 	
> We ended up drafting a different slave on a different network so its
> secondary Ethernet card could be successfully set to equal our master
> and things were beautiful once again until . . .
> 
> 	I came in today and noticed that none of the remaining slaves
> were doing zone transfers any more except when refresh time came
> around.  I modified named.conf on each slave to reflect the primary
> interface of the new master and now all those systems are happy until
> we switch back to our normal configuration after obtaining a new
> hardware transplant.
> 
> 	The interface questions are appropriate for the FreeBSD group,
> but I am describing them here as a warning to all who have great plans
> for what they are going to do when this or that happens.  There are
> pitfalls out there and that is one of them.
> 
> 	Now, for the slave update issue.
> 
> 	All our slave files pretty much look like:
> 
> zone "hardknocks.edu" {
> 	type slave;
> 	file "hardknocks.zone";
> 	masters {
> 		192.168.50.1;
> 
> 	};
> 	notify-source 192.168.50.1;
> 
> 	notify yes;
>         allow-query { any; };
> };
> 
> 	While I can see that it is possible to have multiple masters,
> is there a safe way to have multiple notify-source addresses?  What is
> happening is that the box appears to send notifies on its primary
> interface and the slaves are seeing them but probably think it is just
> the slave notifies that occur after a slave transfers a zone.
> 
> 	Thanks for any good ideas.
> 
> 	One other little alligator that will bite you when you need to
> promote a slave to a master is a sort of common-sense problem, but one
> that at least nipped at my heals.  Use a script or some mechanical
> method to make absolutely sure that all your slave zone files have
> exactly the same name as they do on the master or named.conf from the
> master won't know how to find them.  We have 184 zones and about 6 or 8
> had slightly different names, just enough to see a bunch of sickening
> messages about "file not found," etc, meaning that the customers
> aren't getting service until you reconcile those names.
> 
> 	Ah, for the day when we can have a massive cluster of boxes
> that all run one instance of bind so that when one bites the dust, the
> rest just slow down a little and only us network folks notice.
> 
> 	Until the crash, bind had been running without a restart since
> November 4 of 2004 and the box, itself had been up 471 days.  It
> speaks pretty well for FreeBSD and bind.
> 
> Martin McCormick WB5AGZ  Stillwater, OK 
> OSU Information Technology Division Network Operations Group

	Well unless you have some reason not to I would just change the
	notify-source to be the master's address.  If you really do
	need notifies going out from two different addresses then
	you need to adjust listen-on etc. and run two instances.

	For FreeBSD the aliases that sit on a existing subnet need a
	netmask of 255.255.255.255

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org