Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Hey guys, Named/BIND is crashing every few days, usually I have few tools that take care of such crash and restart the service but lately they can't really restart it. What's odd is that when I try to manually restart I get this error:

named failed to start named dead but subsys locked

When running this command:

ps aux | grep named

There is some output indicating that the service is still "running" and deleting /var/lock/subsys/named or the pid file won't help. The only thing that help is kill -9 (and I hate running that command)

Looking at my /var/log/messages don't give me much clues about what happened there. What I'd like is to understand what happened there, it bugs me because having my domain name server down is critical.

Could you share if you had similar problems? or how I could investigate further such problems?

I am running centos 5.3 - 64bit - kernel: 2.6.18-128.2.1.el5.028stab064.4 / BIND 9.3.4-P1

Thanks,

share|improve this question
    
As you probably know, all BIND 9.3 versions are end-of-life and 9.3.4-P1 has 4 known vulnerabilities so you may also want to look into replacement with a more recent version, isc.org/software/bind/versions –  mas Aug 13 '09 at 9:25
    
Thing is that this is the latest stable version in centos 5.3 repository, I don't believe in updating from other repositories since it might jeopardize the stability of my server. –  Adam Benayoun Aug 13 '09 at 9:48

4 Answers 4

up vote 1 down vote accepted

The version of BIND that you are running seems to be susceptible the remote denial of service recently advertised in CVE-2009-0696. Exploits are available in the wild and your frequent crashes may relate to this. I'd advise you to upgrade as soon as you can and then see if the problem persists.

share|improve this answer
    
+1 IS there a way to determine if the service was subject to an attack? –  Adam Benayoun Aug 13 '09 at 9:25
    
Seems that the bind version I am using is the latest stable version available for centos 5.3 2 weeks ago an important security update was dispatched, and I've updated it to bind-9.3.4-10.P1.el5_3.3.x86_64.rpm –  Adam Benayoun Aug 13 '09 at 9:36
3  
If that is the standard build (and uptodate) from the CentOS repositories, then you may find that the fix for that DoS problem has been back-ported. This is common for distributions that concentrate on stability over cutting edge (RHEL, on which CentOS is directly based, and Debian/Stable for examples) –  David Spillett Aug 13 '09 at 11:41
1  
I can't remember off the top of my head how the crash is logged. It's a few weeks since I tested it. As far as I know the daemon will just exit. David's right about the back-porting, which is indicated by -10 in the RPM name you just gave. Was that the version you were running prior to the crashes? That kind of version identification is one of the reasons I'm not a great fan of back-porting. –  Dan Carley Aug 13 '09 at 12:14
    
yes, this version was running prior to the crash. thanks guys for the help. –  Adam Benayoun Aug 13 '09 at 12:27

Centos is my preferred distro but for important components such as bind I wouldn't even consider using the repositories, as they can be quite out of date. I suggest you do likewise and compile from source. Long term it's more maintainable and predictable that way. BTW, what does rndc status show?

share|improve this answer

If you want to confirm that your BIND instance isn't vulnerable to the recent DoS vulnerability, try running this exploit code against your server. Make sure you're logged in to the machine so you can restart BIND if it crashes :-)

share|improve this answer

I know this isn't strictly in line with the question, but on a security note you should identify whether you need the features of bind or whether you could get away with one of the alternatives. Djbdns is significantly more secure, and powerdns and maradns aren't far behind. Bind is an old, massive, and complicated program, that never the less excels at what it does but is also quite labyrinthine. Complexity is the enemy of security, depending on your needs and the size of your managed domain you may nbe better off with one of the other available options.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.