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 <[EMAIL PROTECTED]> 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
