Here is how to fix your nameserver - was Re: BIND update?

[Ted Mittelstaedt]

> -----Original Message-----
> From: stakys [mailto:stakys at punktas.lt] 
> Sent: Thursday, July 10, 2008 2:30 AM
> To: Ted Mittelstaedt
> Subject: Re: Here is how to fix your nameserver - was Re: BIND update?
> 
> >
> >   
> According to your simple steps everything runs fine for now. 
> What about 
> later then the port will be available or the 6.4 is out? How 
> the update 
> procedure should look like, or it would be the same as always without 
> any hints for BIND?
> 

Hi Stakys,

  I hope you don't mind I'm ccing this to the list as others
may have questions.  Incidentally, if you use my instructions
there is one other thing you have to do, that is you have to
put a copy of rndc.key into /etc because rndc out of the box
defaults to looking there for it.

  With regards to the ports, yes you can do it that way if
you want.  I myself haven't used the BIND port in the ports
directories so I am not aware of all implications of using
it.  I presume it replaces all the BIND utilities in the base
system with updated versions.  What isn't clear to me is
what the port does with every other program in the system
that is linked into the BIND resolver functions.

  If your admining a nameserver and you routinely use the
BIND port, you should continue to do so, NOT use my instructions.
If you have never used that port, then you might consider
it.  But, I would do it on a nameserver your prototyping,
so you can learn how the port operates.

  Keep in mind that there is no "right" way to admin your
system - it is your system, do as you want.  Because FreeBSD
is self-supported, the security patches, the ports, and
ad-hoc instructions like mine are purely out there for
people to use IF THEY WANT TO.  You do not have to admin your
server the way that -we- say to do it. ;-)

  Just as a bit of background on UNIX.  There was NEVER a
standardized place to put things in the UNIX filesystem.  For
example, Sun likes to use the /opt directory a lot, and
no other UNIX does that I know of.  There's de-facto places.
That is why the ports directories are so important, because
when a port for a utility is created it standardizes where
everything goes.  For example, if someone says to the list
that they used the BIND port to install an updated version
of named, we -know- for example that named.conf is going to
be at /var/named/etc/namedb/named.conf because that is where
the FreeBSD Release engineers decided to put it, and the
person who created the port is of course going to honor that.
BUT, that is a compile-time option in BIND and the defaults
in the BIND source don't actually put it there.  Instead they
put it in /etc/namedb/named.conf

  When a UNIX vendor (and the FreeBSD Project is a UNIX vendor,
they just don't get paid for it like a commercial UNIX vendor
like Sun does) creates a UNIX distribution they draw software
from all over the globe. Sendmail comes from here, gcc comes
from there, named comes from this other place, etc. etc. etc.

  Each of those individual packages has their own places that
they put things.  Part of the job of the release engineer is
deciding a logical structure on -their- UNIX release of where
things go, and then putting in compile time options, or patching
makefiles, or even patching source itself, of all these different
utilities to force them to put their stuff where the release
engineer has decided to put it.

  Back in the bad old days of UNIX, most of the Really Useful
utilities -weren't- included in the UNIX distribution.  For
example ALL Solaris UNIX versions up until very recently didn't
even have a compiler, you had to bootstrap gcc into your
Solaris system.  HP/UX, and Utek UNIX had compilers, but they
were crappy ones and wouldn't compile most programs, so you
had to use their crappy compilers to build a better compiler
then use that compiler to build basic tools - things like Perl,
Bash, php, and so on.  Quite a lot of work, and nowadays
we have it a lot easier - BUT the PROBLEM is that because
so many basic utilities are now supplied stock out of the box,
if you want to replace one of them, because of a security
vulnerability like this named thing, for example, it becomes a
MAJOR PIA.

  Looking at Perl for example illustrates this.  Perl is a
rather nasty program to have people build because it is so
involved - but it is a fantastically useful program.  In
FreeBSD 4 days it became obvious that it would be Really 
Useful if Perl was included in FreeBSD, so they did so.
Then it became even more obvious that it would be even
more Really Useful if Perl -wasn't- included, precisely
because of stuff like what is going on right now with
BIND.  So, they reverted to the old way of doing things,
and Perl is back to being an add-on, one that virtually
everyone who is setting up a FreeBSD system immediately
installs as soon as they setup a new FreeBSD system.
(hopefully, from the ports or packages system)

  So, getting back to BIND.  Unfortunately, BIND isn't as
easy to create as an add-on as Perl is.  BIND is more than
a simple program.

BIND has 2 parts, there's a set of libraries, usually referred
to, generically, as the "resolver libraries"

There's a set of utilities, like named, named-xfer, rndc, and 
so on.

Just about every network-aware program in ANY unix, ie: sendmail,
nslookup, host, netstat, etc. etc.  is compiled to link in
the resolver library.

If a flaw in the libraries is discovered, it affects -ALL-
network-aware programs that are linked into the libraries.
Thus, the only real fix is to update the source for the
system and recompile every single utility that is linked into
the resolver libraries in the entire system -including-
additional utilities that are built by the user after the
system is installed.  (ie: do a make world)  With FreeBSD,
during the system build process, the BIND resolver routines
are put into libc.  (ie: /usr/lib/libc.a for the static
library, and /usr/lib/libc.so for the dynamic one)

While it is sometimes possible IF the utility is dynamically
linked to simply recompile the resolver library, this is a Beware,
There Be Dragons kind of thing to do because if the library
has changed much, you can introduce problems that way.
And, with FreeBSD, libc has a lot of -other- stuff -besides-
the BIND stuff in /usr/src/lib/libc/resolv   It's probably
accurate to say that virtually everything in the system is
linked into this library.

Thus, "upgrading BIND" if your talking about -everything-
that makes up BIND is not simple.

HOWEVER, this particular issue ONLY affects systems that are
acting as nameservers because it only affects named itself.

Virtually all FreeBSD systems are NOT running as nameservers
and thus do not need to worry about this particular notification.

Systems that ARE running as nameservers almost always are doing
that ONLY, ie: they are dedicated nameserver servers.  Thus
your not using most utilities in the system, sendmail, host,
netstat, etc.

Because, when named is built it -statically- links into it's
libraries (which are also built when named is built), thus when
you follow my instructions you are ending up with a system that
has the -old- resolver libraries that are linked into every
other program in the system, and a named program that is built
with the -new- code.

Since the vulnerability only affects named, it doesn't matter
that the rest of the system is using the old code.  And,
by NOT replacing the old libraries, you avoid introducing
potential instabilities into other programs.

For example suppose in addition to nameserving your server is
doing some analysis of traffic - if you recompile the world
with the new resolver library and the analysis code your
running breaks, well now you are stuck because you don't know
if the problem is in the new resolver code or if it is
that you improperly compiled it into the system, or if
it is because some other utility that linked into libc
has a problem.

My instructions basically give the nameserver admin a way to
patch their server in the most -minimally invasive- way possible
and then run it that way until the next version of FreeBSD is
released in August or September.

Ted