BIND Version 8 Features

Wondering about the latest version of BIND? Wonder no more--Mr. Harari is back this month to tell us all about it.

by Eddie Harari

Many new features have been compiled into the new version of BIND (Berkeley Internet name daemon), including security bug fixes and several major changes that give the network administrator the needed tools and configuration options to achieve essential tasks unavailable in earlier versions of BIND.

Configuration Syntax

The first thing we need to know is that a few of the terms were changed. There are no more primary servers or secondary servers; these two terms have been replaced with master server and slave server.

The first major difference you will notice in BIND 8 is the configuration file syntax is completely different. This is confusing at the beginning. Until you learn the correct syntax and features, you may use a Perl script that converts from the old style /etc/named.boot file to the new style /etc/named.conf file. Please note that these file names are the default configuration file names for BIND 4 and BIND 8.

Listing 1

The BIND 8 configuration file syntax has a modular style. Each and every section is surrounded by ``{ }'' and each line is terminated with a ``;''. Each zone has its own section in the configuration file. Listing 1 is an example of a very simple configuration file.

Files and Utilities Location

With BIND 8, it is possible to change the location of some named files, such as named.pid, named.stats, named-xfer and a few others, with the following statement in the options section of the configuration file:

options { 
   named-xfer "/
   };

This example changes the location of the command executed when the name server wants to make a zone transfer.

Name Checking

BIND 8 also checks the host names in its databases. It checks for conformance to RFC 952. If there is a host name in the zone database which does not conform to the RFC, BIND 8 will consider this zone to have a syntax error and will not load it. This can cause problems for people who are upgrading from earlier versions of BIND and have host names which do not conform, such as names with underscores. If you are upgrading from an earlier version of BIND, and don't want BIND to check the names of your hosts in the database, you can use the following option:

options {
             check-names master warn;
             check-names slave ignore;
             };

This will tell the server to send warning messages instead of errors when ``bad names'' occur in a zone for which the server is a master, and ignore ``bad names'' in zones for which the server is a slave. You can also ignore bad names in the server, but this is not a good thing to do since BIND 8 also checks names in response to queries. If you are a master for a zone which has bad host names in it, some Internet servers will not accept your server's replies. If you want your server to accept replies even if the host names do not conform with the RFC, use the following line in the options section:

check-names response ignore;

Logs Configuration

BIND 8, unlike older versions of BIND, gives the network administrator full control of the logging messages it produces. This logging does not have to go through the syslog daemon. Error, debug and other messages can be configured to go to the syslog, to a file or to standard error (STDERR). This is done with the help of two things: channels and categories. A channel is configured in the configuration file and tells the name daemon where the logged data should go. A category tells the name daemon what kind of data should go there. The message severity can be one or more of the following: dynamic, debug, info, notice, warning, error and critical.

Here is an example of a logging statement in the name daemon configuration file:

logging {
       channel my_new_logging_channel {
       file "named.messages";
       severity dynamic; 
       };
};

This statement tells the name server to log all current debug-level messages in a file called ``named.messages''. Some nice features are available for logging, including log-file versions, default operations, log-message format and more. You should refer to the README file and to the documentation that comes with BIND 8 in order to fully understand how the logging statement works.

Security and Privacy

System and network administrators can now decide which servers and hosts will query their server for each and every zone they serve. This is done via access lists. With access lists, we can tell the name daemon which hosts or networks can send queries to a particular zone. Access lists are defined by a name in the name daemon configuration file. An access list is basically a set of IP hosts or network addresses assigned to a zone in the zone section. An access list can be constructed from the names of other access lists defined in the configuration file. Here is an example of an access list:

acl "MySlaveServers" {
	    {192.168.1.1/32;};
 	    {192.168.2.0/24;};
	    };

This means whenever we use the access list ``MySlaveServers'' in the configuration file, we want to specify the host 192.168.1.1 and the network 192.168.2.0. The /32 and /24 are the number of bits in the bit mask of the IP address. The predefined access lists in BIND 8 are None, Any, Localhost and Localnets.

Localhost: any of the IP addresses of this host.
Localnets: any of the IP networks to which this host has an attached interface.

After we have defined the access list, we can use this access inside a zone section or in the options section:

zone "myzone.mydomain.name"  {
   type master;
   file "mydomain.db";
   allow-query { any; }; // This is default,
                         // But good as an example
   allow-transfer { "MySlaveServers";};
   // Others cant zone transfer ...
   };

This configuration example gives anyone the ability to query ``myzone.mydomain.name'', but zone transfers can be done only from 192.168.1.1 or 192.168.2.0. We can put the access lists in the global options section, and it will be applied to all zones specified in the configuration file. With the allow-query statement, we can handle inside domains even on our external DNS server; to do that, we simply need to set up our internal zone so that only our internal networks can query host names of that zone.

Daemons often run with root permissions. This was also the case with earlier versions of BIND. With BIND 8, named can run as a different user. It is a good idea not to run named with root permissions, for security reasons. If someone exploits the name daemon and tells it to run arbitrary code, then this arbitrary code should not be run with root permissions. The best thing to do is create an account and a group for the name daemon. The command that tells the name daemon to run with a different UID (user ID) is:

/usr/sbin/named -u named -g namedgrp

This command will tell the name daemon to run with the UID of the user ``named'' and the GID (group ID) of the group ``namedgrp''. We must first create this user and group. When running named with a UID that is not root, we must ensure that the name daemon database's permissions and ownership are set correctly. We can change the permissions with the chmod command, the group with chgrp and the ownership with chown.

Notification Messages

Older BIND versions used the following method to synchronize the database between the master server and the slave server. From time to time, the slave tries to invoke named-xfer with the correct zone parameters and the zone database serial number. If the server has a higher database serial number, it will give the slave its new database and update the slave. The database polling interval is set up by the master server inside the zone's database SOA (start of authority) record, and it is known as the refresh-time parameter. This can cause a big delay between updating our master server and the time the data is available all over the Net.

BIND 8 has one more method for synchronizing zone databases between the master and the slave servers. This method is known as the DNS NOTIFY message. The NOTIFY message is basically a message the master server sends to its known slaves whenever a zone's serial number is changed. A NOTIFY message is simply a DNS QUERY message with the opcode NOTIFY inside the message. The slave, after getting the NOTIFY message from the server, replies to the server with a NOTIFY response, telling the master server to stop sending the NOTIFY to this particular slave. Then this slave can continue to send named-xfer requests to the server in order to update the zone information. The configuration parameter, which tells the server whether it should or shouldn't send NOTIFY messages when the zone database changes, is notify, as seen in this example:

zone  "my.domain.sela.co.il" {
      type master;
      file "db.mydomain";
      notify yes;
      };

Sometimes there are DNS slave servers in our zone which are not registered as NS (name server) records inside our zone's database. NOTIFY messages are sent only to those slaves that are registered inside the zone database as NS records. If we know about an unregistered slave server and want our master server to send a NOTIFY message to this slave whenever the zone database changes, we can do that with the also-notify keyword in the zone section of the name daemon configuration file.

zone  "my.domain.sela.co.il" {
 		    type master;
		    file "db.mydomain";
		    notify yes;
		    also-notify 10.1.1.1;
		    };

This configuration section tells the name daemon to notify the registered slave servers whenever my.domain.sela.co.il is changed, and also notify the 10.1.1.1 machine even though it is not registered as an NS record in the my.domain.sela.co.il zone database.

Dynamic Updates

BIND 8 allows authorized hosts to send the zone master server an UPDATE message. An UPDATE message can add, delete or change record information in the zone's database. The machine that sends the update message tries to find the master server for the zone from the zone's NS records. If the message is received by a slave server instead of the master server, the slave server should forward the message to the master server.

Dynamic updates are a good thing for hosts which get their IP addresses dynamically from a RARP (reverse ARP) or DHCP (dynamic host configuration protocol) server. These hosts can send an update message to the DNS server after they get their IP address from the DHCP/RARP server. The new resolver library routine, ns_update, is used by programs to send DNS update messages to the server. BIND 8 is shipped with a command-line utility, nsupdate, that gives the ability to send update messages to the zone's master server. By default, no one is allowed to dynamically update a zone; the configuration file keyword allow-update gives the system administrator the ability to configure the hosts which can send update messages for each zone. This update can help DNS and WINS to live together on the same network, since WINS also uses a dynamic-update method.

zone  "my.domain.sela.co.il" {
		    type master;
		    file "db.my.domain";
		    allow-update { 10.1.1.1;  };
		   };

This example lets the host 10.1.1.1 send update messages containing information on the my.domain.sela.co.il zone.

Conclusion

BIND 8 has many nice features, some of them needed by many network administrators. Since major security holes were discovered in earlier versions of BIND, upgrading to BIND 8 is almost a must. There are still stable older versions, such as 4.9 and later, but these do not support all the functions mentioned here.

Eddie Harari (eddie@sela.co.il) works for Sela Systems & Education in Israel as a senior manager and is involved in some security projects. He has been hacking computers for 13 years.