BIND modularity - was Re: cTLD and DNS upgrade

[Joseph S D Yao]

On Thu, Jul 07, 2005 at 10:45:28PM -0400, Kevin Darcy wrote:
...
> Stephane,
> Think through what you're saying here. You say you want the ability to 
> compile BIND with some sort of "authoritative-only" flag. Fine. But 
> you're still going to want something to resolve Internet DNS names 
> right? After you've built your "authoritative-only" executable, are you 
> then going to compile BIND *again* with some sort of "resolver-only" 
> flag? So now you have two different executables that you need to manage 
> (probably with the same name, which could be very confusing). Now, let's 
> say a CERT warning comes out for a vulnerability in one of the common 
> routines that is linked into *both* of your executables. Now you have 
> two rounds of patching to do instead of just one, and if you happen to 
> miss one of those executables on one of those machines, you could be 
> open to attack. Twice as many chances to fail, twice as many chances to 
> get hacked. How is this better, from a security standpoint, than having 
> a single executable in the first place?
> 
> I agree, if you *only* serve authoritative zones, or if that's your 
> primary line of business, then it might make sense to have a specialized 
> program to do that. But for most of us, BIND is a general-purpose tool, 
> something we use more or less equally to *resolve* DNS names as to 
> *serve* them to outside clients. When used that way, it makes little 
> sense to have different compile-time options for different "flavors" of 
> named that you intend to run simultaneously in your infrastructure. That 
> just complicates the job of building, installing and maintaining BIND.
> 
> - Kevin


Kevin,

In all fairness, you would do ONE round of patching, then run 'make' and
'make install' [and 'make install DESTDIR=/elsewhere'], on most recent
systems.

The concept of having a number of smaller programs that each do one
thing and do it well is a very valid concept in software engineering.
This makes the modules into separate processes.  I understand that this
is one of the advantages of postfix [which I really have to study more
when I have time] over sendmail.  However, if a number of the modules
have to communicate a large amount of data wth each other, that
introduces a certain complexity which may outweigh the advantages of
placing the modules in separate processes.  BIND 9's design - again,
what part of it I've had time to see - is much more modular than that of
previous versions of BIND, and I posit that they have decided to keep it
monolithic at least in part because of the problem of sharing data. [I
would appreciate a current developer commenting on this.]

It is an intriguing idea to actually #ifdef out large sections of
functionality that won't be used by your server, instead of just
disabling it by configuration constants.  It would take a good bit of
work and testing.  I would guess that keeping up with RFC requirements
and security additions would keep this from getting to the top of the
to-do list, though.


-- 
Joe Yao
-----------------------------------------------------------------------
   This message is not an official statement of OSIS Center policies.