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

______________________

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