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.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.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState