NameSurfer is ideal for Network Computing's distributed labs, which need access to specific zone information, much like departmental delegation. It's also appropriate for single-zone administration, as well as large ISP implementations that let customers update their own information.

I recently upgraded our University of Wisconsin real-world lab's existing NameSurfer 1.2 installation to NameSurfer 2.0 beta 12. Although the upgrade was somewhat difficult--it involved compiling source code and performing some manual file manipulation--the reward was a faster implementation with an improved interface. I recommend NameSurfer for any organization with multiple administrators who frequently change DNS data.

NameSurfer's top asset is its ease of use. Administrators can access the DNS data from a Web browser. Updates are easy and the changes occur instantaneously with DNS Notify (RFC 1996). In addition, support teams can access DNS updates without the assistance of a Unix guru, and all updates are logged for future use.

From the Start Installing NameSurfer on an existing DNS server is simple: All of your existing data is automatically imported. I originally installed NameSurfer on a new server, and from there I clicked on "Import from another server." With the entry of the zone name and the primary DNS server, NameSurfer imported the DNS date over the wire. After conducting a few imports and creating a few subadministrator accounts, my NameSurfer server was ready to go--no text-file editing needed.

NameSurfer doesn't actually replace the current implementation of BIND (Berkeley Internet Name Domain) on your server; rather, it modifies the executable to interact with NameSurfer. The new DNS data is stored in a proprietary format and served through a hidden DNS server that listens to Port 8054 (DNS is usually on Port 53). In a sense, two DNS servers operate--one to maintain the NameSurfer data and another to cache that data, perform recursive lookups and respond to queries.

Keeping your data updated has never been faster because NameSurfer supports secondary updates using the DNS Notify protocol. Whenever DNS data is updated through NameSurfer, all secondary servers for that zone are notified of the change. To work properly, all secondary servers need to be patched before they can make zone transfers from NameSurfer (using Port 8054).

Security and Control NameSurfer makes delegating authority effortless by allowing several users with different access privileges. During testing, I configured an account for each of our distributed labs and let them change only the appropriate subdomain and reverse mapping zones. Two administrator accounts are allowed to manage the entire server configuration.

With any change to any DNS zone information, the log file is updated and an undo is stored. During testing, I accidentally added a host twice, allotting two IP addresses in NameSurfer. By simply using the undo feature, I corrected the error.

NameSurfer uses a Perl-based Web server to interact with the Web browser front ends. I would like to see the implementation of Perl within an existing Web server. This addition would provide the option of enabling SSL (Secure Sockets Layer) encryption. Data Fellows says it is planning an SSL-enabled version of NameSurfer later this year.

Dynamic DNS also is implemented in NameSurfer. However, since Dynamic DNS doesn't have any built-in security, it is disabled by default. When security is added, Data Fellows will implement it along with the specification.

Send comments on this article to Robert J. Kohlhepp at rkohlhepp@nwc.com.