BIND Version 8 Features

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.

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.

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.