The FreeBSD Diary

The FreeBSD Diary (TM)

Providing practical examples since 1998

If you buy from Amazon USA, please support us by using this link.
[ HOME | TOPICS | INDEX | WEB RESOURCES | BOOKS | CONTRIBUTE | SEARCH | FEEDBACK | FAQ | FORUMS ]
Upgrade your DNS server - bind8 security issues 20 November 1999
Need more help on this topic? Click here
This article has no comments
Show me similar articles
This 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:

http://www.isc.org/products/BIND/bind-security-19991108.html

The install
Since I have the entire ports tree installed, all I needed to do was:
cd /usr/ports/net/bind8
make
make install
The configuration
This 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:

named_program="/usr/local/sbin/named"

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 named
First, I killed the existing named:
killall -QUIT named

Then I started the new named:

/usr/local/sbin/named
The logs
Checking the logs I found this:
Nov 20 05:34:01 ducky named[53387]: starting.  named 8.2.2-P5 
   Sat Nov 20 05:07:59 NZDT 1999
   root@ducky.nz.freebsd.org:/usr/ports/net/bind8/work/src/bin/named
Nov 20 05:34:02 ducky named[53387]: hint zone "" (IN) loaded 
   (serial 0)
Nov 20 05:34:02 ducky named[53387]: 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[53387]: 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:

$TTL    345600

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.


Need more help on this topic? Click here
This article has no comments
Show me similar articles