Network Computingwww.networkcomputing.com

IP networking has grown from the Unix world, so most deployed DNS models run on Unix platforms. Berkeley Internet Name Domain (Bind) version 4.9 is the preferred DNS package for most administrators, making Bind 4.x interoperability essential for most cross-platform DNS deployments. However, the Internet Software Consortium (ISC), the group that maintains the Bind package, has stopped development on version 4, encouraging administrators instead to upgrade to the latest release of its free DNS implementation, Bind 8.

Bind 8 substantially improves upon the 4.x distributions, with dynamic DNS updates, DNS change notifications (per RFC 1996), IPv6 support, advanced logging and security options, and noticeable performance increases. (See www.isc.org/bind8/config.html for a full description of Bind 8's features.)

The Bind 8 package makes some logical changes to the traditional DNS model. In the world of Bind 4, name servers fall into the categories of primary, secondary or caching. Bind 8 moves to a "master-slave" model: Masters contain the source zone data while slaves keep copies of the masters' zones. In addition, the traditional "named.boot" file has been changed to a new format that's necessary to accommodate all of Bind 8's additional features. Fortunately, anyone who wants to convert a significant number of zones to the Bind 8 format will appreciate ISC's inclusion of a Perl script, called "named-bootconf," to assist in the process. We ran the script during our own upgrades, and it converted all our zones without incident.

One incentive for upgrading to Bind 8 is its vastly improved handling of zone transfers. With older DNS servers, the interval at which a secondary server would check the primary server for updated information was static. Depending on the settings, a secondary server's data could be inconsistent with that of the primary server for hours, or even days. Bind 8's use of a NOTIFY message (see RFC 1996) decreases convergence times between the master and its slaves. When a zone is updated (and its serial number is changed), Bind 8-based servers automatically send a NOTIFY message to the slave server. The slave server then checks for an update to the zone and initiates a zone transfer, if necessary. Another improvement (also present in patched versions of Bind 4) is the efficiency of the zone transfer itself. Older DNS implementations send one DNS message per resource record transferred; the improved mechanism packs as many records together as possible.

Bind 8, as well as a few of the newer DNS packages, also implement DDNS (Dynamic DNS, RFC 2136), which many call "WINS [Windows Internet Naming System] done right." DDNS allows for the external and dynamic updating of a specified zone by other hosts or processes. Clients with DDNS functionality can update local name servers with current information. However, a more robust design uses an integrated DHCP-BOOTP and DNS structure. DDNS-capable DHCP servers can send a record update to the appropriate DNS server based on a DHCP client's NetBIOS name. The update occurs after the IP address lease is negotiated and is removed when the lease expires. The synergy created by marrying DNS with DHCP gives administrators a powerful mechanism for IP host autoconfiguration.