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.

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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix