Traditional DNS

In the past, DNS has been administered by building a database of information that includes all of a zone's resource records into a textual file. Novell's earlier support of DNS used Btrieve as its database. Other vendors also use large files to store the information required for a DNS zone. The administration of these files is difficult and cumbersome.

Traditional DNS Structure represents a traditional DNS strategy. A zone, such as novell.com, would have a master DNS server handling queries about the entities within it. A DNS server might support more than one zone, and it would probably have at least one secondary server for backup (redundancy) or load-sharing purposes. The master DNS server provides DNS name service for two zones: novell.com and other.com. The secondary DNS server provides backup support for the novell.com zone, and the other secondary DNS server provides backup support for the other.com zone.

Additionally, each name server maintains separate copies of the zone data for primary and secondary support. When changes occur, all of these files require updating with zone transfers, which greatly increases network bandwidth use.

Figure 5
Traditional DNS Structure

The file storing the RRs for a zone might have hundreds or thousands of entries for different types of resources, such as users' addresses, hosts, name servers, mail servers, and pointers to other resources.

When a client initiates a request to resolve a domain name to an IP address (perhaps by using an Internet browser or by sending e-mail), the client sends a query to the name server specified in the client's configuration. The name server that receives the query will search its authoritative zone information for the desired record. If the record cannot be found, the name server will forward the query up the hierarchy to the name server above it for resolution.

When updates are made to the master name server, the entire contents of the database file must be copied to any secondary name servers.