Trying to understand DNSSEC and BIND versions better

[Chris Buxton]

On Jun 10, 2009, at 7:01 PM, Chris Adams wrote:
> Once upon a time, Chris Buxton <cbuxton at menandmice.com> said:
>> On the other hand, the builds from the Linux vendors have been less
>> than perfectly stable at moderately high levels of traffic.  
>> Rebuilding
>> from stock source code has always fixed this problem. We've seen this
>> problem with both the Red Hat build and the Debian build.
>
> What do you mean by "moderately high levels of traffic"?  We run  
> RHEL 5
> and its build of BIND with no troubles.  I don't really see anything  
> in
> the source RPM for BIND that would cause it to be any more or less
> stable than a build from the standard distribution (modulo stability
> bugs in specific BIND versions itself).

I can't really be any more specific than I have been - the servers in  
question are not our servers, and I'm not able to analyze the source  
code of the patches and of BIND to see what might be causing problems.

A few of our customers, running servers that they describe as  
experiencing high traffic (by their own standards), have had to have  
us rebuild BIND from the stock source code for them to solve frequent  
crashing during such high traffic episodes. Frequent in this case  
typically means that named either just dies or dumps core within a few  
seconds of starting up.

The Red Hat BIND SRPM applies a variety of patches that have been back- 
ported from later versions. These patches appear to not be 100%  
compatible with the older code they use as a base. When we have torn  
apart the SRPM, replacing the base source code and disabling all  
patches except the one that changes the path to the PID files, and  
then rebuilt the RPM, the result has been able to hold up for these  
customers. In such cases, we're not changing the configure options,  
we're installing the result on the same servers that are falling over  
with the RH-supplied version, and the result is a server that runs and  
doesn't crash or dump core.

We have not bothered to build a .deb package for Ubuntu, just compiled  
the stock source code with fairly standard options. Again, this has  
always solved the problem for the affected customers. One such case  
was the most reliable at producing rapid core dumps that I have  
personally seen, until we upgraded them.

Chris Buxton
Professional Services
Men & Mice