Strange Firewall Behavior with bind

[Martin McCormick]

	I administer 3 master BIND 9.3.3 DNS's under FreeBSD6.2,
soon to be upgraded to 6.3 and the patched version of bind, but
here is the problem. 2 out of the 3 DNS's work perfectly, one of
which is very busy, and the 3RD DNS, on our quietest remote
campus will stop being able to query outside our network even
though bind is still running and logging just fine.

	The problem is always cured with a reload of the
firewall rules and only effects port 53 traffic which is why I
am asking this list what could be triggering this misbehavior?

	All our DNS's are pretty much carbon copies of each
other except for zone names, IP addresses, etc, so one would
expect all the others to be going deaf every 1 to 4 weeks and
needing the same treatment, but they don't.

	Is this behavior between named and ipfw familiar to
anybody?

	The firewall rules regarding port 53 traffic on all our
working systems are:

	${fwcmd} add pass all from any to ${ip} 53 keep-state
	${fwcmd} add pass all from ${ip} to any 53 keep-state
#Provide an alternative path if things get busy.
${fwcmd} add  allow ip from any to ${ip} dst-port 53
${fwcmd} add  allow ip from ${ip} 53 to any // allow reply traffic
${fwcmd} add  allow ip from ${ip} to any dst-port 53
${fwcmd} add  allow ip from any 53 to ${ip} // allow reply traffic

The last 4 lines are because our master has gotten so busy at
times that the log complained of too many dynamic rules so maybe
keep-state isn't the best setup.

	The problem system only has the last 4 rules but is
still going away every week to a month or so. As I said, it is
the quietest DNS of all of ours. All are on systems that are not
heavily taxed or otherwise in distress so I am mystified. Folks
are starting to do things like asking if we need to rebuild the
server and rebooting the whole system when it misbehaves so I am
in need of some constructive suggestions to make this problem
go away. All are using the "client" firewall rules which means
anything not expressly allowed is prohibited.

Thanks for any ideas.


Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Network Operations Group