etch/bind9 problems after OpenSSL and kernel security upgrade
Hi.
I work for a DNS-provider with a six-digit number of zones in our main nameserver.
The main nameserver is running Debian etch, kept up to date with security patches from security.debian.org.
After the by now well-known OpenSSL security upgrade (openssl 0.9.8c-4etch1 -> 0.9.8c-4etch3) and a reboot with linux-image-2.6.18-6-686 (2.6.18.dfsg.1-18etch4), named (bind9 9.3.4-2etch1) has become quite unstable. So far, we've had two cases of named just being completely unresponsive, and the first case was during the first startup of named after reboot.
I suspect the problem may be with the changes in OpenSSL from 0.9.8c-4etch1 to 0.9.8c-4etch2 (0.9.8c-4etch2 was never released through security.debian.org, so the changes were rolled up with the 0.9.8c-4etch3 release).
It's fairly hard for me to provide a really good test case. Our named.conf is 10 MB and contains 130k zones, and named uses 25 minutes to start in the best of times, sometimes up to an hour or so. It's not realistic to perform testing on this platform.
According to the changelog for the openssl package, the changes that aren't related to the security fix are:
openssl (0.9.8c-4etch2) proposed-updates; urgency=low
* Apply patch from SuSe for CVE-2007-4995. This should also
get DTLS in a working state.
* Fix CVE-2007-3108 wrong Montgomery multiplication. This was
also included in the patch from SuSe. (Closes: #438142)
-- Kurt Roeckx <kurt@roeckx.be> Sun, 06 Apr 2008 16:31:28 +0200
CVE-2007-4995 seems pretty serious, so it's a bit strange that the
urgency was low, but would it be fairly easy to regress to
0.9.8c-4etch1 with patches for CVE-2007-4995 and the random seed
problem only?
Am I barking up the wrong tree here, and should I instead be looking at problems in bind9 itself, or even the kernel? It does seem too much of a coincidence that these problems only started occurring after the OpenSSL + kernel upgrade, though.
--
Jan
Reply to: