Whether you're hosting a single zone for your organization or hundreds of zones for hundreds of customers, not restricting unauthorized zone transfers is foolish. "Name server dumping" is a common method used by the cracking community to help map out a targeted network. Using the "allow-transfer" directive in Bind 8, or the Bind 4 equivalent "xfrnets," administrators can single out individual hosts or subnets that are authorized to transfer zones. Usually this authorization is restricted to secondary or "slave" servers. Bind 8 allows for more granular control over these restrictions, allowing for settings on a per-zone basis. This provides more incentive to upgrade.

While NT 4.x offers zone transfer control via the SecureSecondaries registry setting, for example, NetWare 4 is next to useless in the security arena. Although Windows 2000 and NetWare 5 are slightly more feature-rich, allowing for some restrictions and logging, they still fall short compared to Bind 8.

Bind 8 also takes the lead in protecting internal private addresses. Some organizations use one or many of the reserved blocks specified in RFC 1918. According to the RFC, "indirect references to such [reserved] addresses should be contained within the enterprise. Examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, ISPs should strive to prevent such leakage." In keeping with the RFC recommendations, many DNS administrators choose to run a "split DNS" model--that is, a set of internal name servers in conjunction with external ones that can be queried from the Internet. One way to guarantee that your internal name servers don't answer outside queries is to use Bind 8's "allow-query" option, which lets you restrict the servicing of DNS queries on a per-server or per-zone basis. Restrictions can be applied to a host or network range--a significant improvement over previous versions. Again, Windows 2000's and NetWare's implementations do not offer this type of granular control.

There are also some considerations to take into account when dealing with DDNS. RFC 2137 specifies the framework for conducting secure updates within a dynamic DNS environment using digital signatures. Windows 2000, NetWare 5 and Bind 8 don't implement these secure signatures. However, ISC is working to meet RFC 2137's specifications in Bind's next release.

Finally, with the recent rounds of remotely exploitable root-level holes discovered in Bind, administrators running Bind 4.x-based distributions should upgrade, or at least patch, their systems as soon as possible. (You can check your version of Bind by using the "dig" utility: "dig@name server version.bind chaos txt"). The patched versions fix the hole associated with inverse queries and inoculate Bind against a range of denial-of-service attacks.

On the Horizon As with all evolving protocols, not all options are implemented by all vendors. In an effort to maintain a unified DNS front, Digital Equipment Corp., Hewlett-Packard Co., IBM Corp. Silicon Graphics and Sun Microsystems are funding ISC in developing a greatly enhanced Bind version, expected next year. The rewrite should include support for multiprocessors, improved handling of extremely large zones, zone signatures, encryption based on RSA and DSA (Digital Signature Algorithm), and additional bug fixes.

While many of DNS' newer features are implemented in shipping code, the IETF is working on a host of other improvements, one of which is a large undertaking concerning a pseudo-DNS PKI (public key infrastructure). One security problem that has plagued the Internet recently is DNS spoofing. TSIG (transaction signatures) is aimed at fixing this. Using signatures provided by name servers in the DNS hierarchy, TSIG will let clients receive signed responses from known zone authorities, alleviating any doubt about the authenticity of the response. While it requires more overhead, this feature will greatly benefit the Internet community when it matures.