Ted Mittelstaedt
2008-Jul-10 18:15 UTC
Here is how to fix your nameserver - was Re: BIND update?
> -----Original Message----- > From: stakys [mailto:stakys@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