BIND 9.2.1 - Hanging HELP!!!

[rmueller58]

We are having a problem on a box that acts as our primary DNS machine running Redhat 9.0 and BIND 9.2.1.. Periodically it quits replying to DNS requests, we clear the cache with
rndc flush, sometimes, that does not work we have to kill -9 named processes. and restart. Sometimes it hangs and halts the system altogether.

I've looked in /var/log/messages there are RRSets and some lameserver entries but we can't seem to isolate what the problem truly is.

The hardware is a Dell server, it'd had been working fine for a couple of year and as it was we'd have to rndc flush periodically (once per month..) now it is occuring daily.

Need Help

[Steven E. Protter · Accepted solution]

Shalom,

Check that you have a complete install:

bind-chroot-9.2.4-16.EL4
bind-utils-9.2.4-16.EL4
bind-devel-9.2.4-16.EL4
bind-libs-9.2.4-16.EL4
bind-9.2.4-16.EL4


You do't need devel or libs.

If you are missing one of the big three it could explain all.

Consider rpm -e and re-install

SEP

[Ivan Ferreira]

Your red hat and bind version are old. It's very recommended to upgrade your versions.

What is the output of:

dig yourdomain.com NS

When the problem starts?

What is the status of the named process (cpu usage and so)

Do you have any IDS tool?

[rmueller58]

Steven,

I believe we may need to do a rebuild.. I had croned a rndc flush I think this may have exacerbated the problems as well.


What's involved in upgrading from version 9.2.1 to a new version of 9.3.y? is it as simple as backing up the /etc/named.conf and zone files? Installing new rev, then moving backup back into place?

this thing has been a bit eccentric for a while now. I think we are considering a rebuild. I just don't like throwing OS changes into the mix and making things worse.

[rmueller58]

Ivan, we can seems to catch anything in the logs, I've looked at system processes via top an nothing seems to be out of the norm.

We are Redhat 9 and Bind 9.2.1.

When we DIG the NS from the command line when the system has gone south the Secondary replies. No IDS tools to speak of. We do have Etherpeek and can use TCPDUMP.

[Ivan Ferreira]

>>>> What's involved in upgrading from version 9.2.1 to a new version of 9.3.y? is it as simple as backing up the /etc/named.conf and zone files? Installing new rev, then moving backup back into place?


Yes, is pretty much that simple.

You should use dig @servername domainname NS to force the use of that specific server avoiding the answer of the secondary servers. Round robind DNS implemented? Is this a multi-homed server?

[rmueller58]

Ivan,

We are a pretty disparate network, We handle DNS for 19 school districts, in a 4 county area, its not a matter of simply telling people to fail over to the secondary for a day while we rebuild. We have primary on one box and secondary on another.

We were thinking we'd re-address the secondary so it's reply to the "IP address" of the primary. Any thoughts on that?

Will there be a problem with secondary on an older version? I am half way thinking I'd take one similar box and get it ready for a total swap..

As it stands, rebuilding is our last option but may be the solution we need.

[Ivan Ferreira]

What I said is that I would that that you use dig @servername yourdomain.com NS when the problem starts, so, dig will be forced to use that server. You can do the test from the localserver. tcpdump to port 53 could help, also, strace to the named process.

If you will actually do the upgrade, the clients should use the secondary name server if the primary is down without need of ip changes or aliases.

Ensure that your TTL configuration is high enough to avoid the secondary from responding to queries.

[rmueller58]

Thanks Ivan and Steven,

We are looking into upgrading BIND to 2.4.30p-1 and or potentially upgrading the OS as well. Running on a 5 year version of Redhat is starting to give me the heeebies. I am pressing mgmt for a subscription to RH we can get ACAD rates and we'd have the support of RH vs Fedora ..

When we put these boxes in place my former manager build one and I built another.. The one I built is running fine, he had installed everything by default and a bunch of daemons were running that shouldn't have even been installed. We aren't doing Japanese translations and he had the WNN junk even running. I recall Samba causing problems as well when first built these boxes, I shut that off as we are using these boxes for SMB mounts we've got one box dedicated to CIFS now.

As is stands we are monitoring the system with those questionable items turned off.
We are in process of laying out a plan for taking one off line and putting a routing statement in the core switch for traffic destined to the primary to go to the secondary and taking the primary off line for a rebuild.

Thanks again. You've pointed out some things that helped.

[rmueller58]

Thanks