Upgrade your DNS server – bind8 security issuesThis article shows how I upgraded bind8. Now that bind8 is included in the base installation of FreeBSD, this article may not be the best way to upgrade. Instead, I recommend that you read installing bind8 from ports.
WARNING: The rest of this article should be considered to be outdated.
Why upgrade?Well, like most upgrades, it’s because of security. The latest bind (bind-8.2.2.p5) fixes a few security holes. For most of us, the holes are unlikely to be encountered. But it’s safer to upgrade. See the following URL for more information on the vulnerabilities this upgrade fixes:
The installSince I have the entire ports tree installed, all I needed to do was:
cd /usr/ports/net/bind8 make make install
The configurationThis was slightly interesting. The new named (the executable program for bind) installed at /usr/local/sbin/named but my existing version was at /usr/sbin/named. But this was easily changed.
I modified /etc/rc.conf to reflect the new location:
I was already running named. Here are the entries from my /etc/rc.conf which relate to named:
named_enable="YES" named_program="/usr/local/sbin/named" named_flags="-u bind -g bind"
The flags passed to named specify the user and the group under which named should run. This places named in a sandbox which increases the security of named. It makes it harder for people to break into your system if an exploit is found with named. Just be sure you don’t give any real access rights to the user and group under which named runs. FreeBSD after 3.3 (I think) include the user id and group bind by default so you don’t have to create them.
Starting the new namedFirst, I killed the existing named:
killall -QUIT named
Then I started the new named:
The logsChecking the logs I found this:
Nov 20 05:34:01 ducky named: starting. named 8.2.2-P5 Sat Nov 20 05:07:59 NZDT 1999 firstname.lastname@example.org:/usr/ports/net/bind8/work/src/bin/named Nov 20 05:34:02 ducky named: hint zone "" (IN) loaded (serial 0) Nov 20 05:34:02 ducky named: Zone "0.0.127.IN-ADDR.ARPA" (file localhost.rev): No default TTL set using SOA minimum instead Nov 20 05:34:02 ducky named: master zone "0.0.127.IN-ADDR.ARPA" (IN) loaded (serial 199907090)
You can see that the correct version of named (8.2.2-P5) is running and the date it was compiled (Sat Nov 20 05:07:59 NZDT 1999).
The messages which refer to a lack of a default TTL can be safely ignored. TTL = time to live. It dictates how long a server can cache information about your box. The message in question is named merely telling you politely that your zone files don’t contain a default TTL. You can specify the default TTL like this:
Put that at the top of each of your zone files and those messages will go away. This value will be used for each host for which a TTL value is not explicitly assigned. In the above case, the default TTL is 4 days as recommended in RFC 1537 This will apply to each host within the zone.
Custom TTL values can be assigned to individual hosts. This is done like this:
1 3600 IN PTR localhost.yourdomain.org.
For more information, I suggest you buy a copy of DNS and Bind. It’s a very useful book when you’re doing anything with a DNS server. That’s how I found how what this message was all about. See p189 for an explanation of how you can use TTL to your advantage when moving or renaming boxes.