Novell is now a part of Micro Focus

Easing TCP/IP Network Management with Novell's DNS/DHCP Services

Articles and Tips: article

PAUL BARTHOLOMEW
IS&T Manager
Novell Inc.

KEN NEFF
Technical Publications Architect
Novell Developer Information

01 Apr 1998


Find out how Novell is integrating Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP) into NDS to facilitate automated management of enterprise-wide IP addresses, host names, and configuration information.

Introduction

The difficulty of maintaining TCP/IP networks has been called "the best kept, dirtiest little secret around." As more and more companies embrace TCP/IP as the networking protocol of choice, system administrators and IS personnel are looking for solutions to simplify the management of TCP/IP-based networks. Many who are accustomed to NetWare's relatively effortless IPX-based device naming and addressing scheme are alarmed to find that TCP/IP does not provide any automatic way to configure IP addresses and other information necessary for network devices to communicate. Even sites that have had their LANs connected to the Internet for years are running up against limitations such as the increasing scarcity of available IP addresses.

In recent years, two technologies have emerged to mitigate some of the inherent difficulties in maintaining TCP/IP networks. One is the Domain Name System (DNS), a distributed name/ address database used to translate between numerical IP addresses and alphanumeric device names. The other is Dynamic Host Configuration Protocol (DHCP), which provides a framework for dynamically passing configuration information to clients or service-providing resources on a TCP/IP network. While there are many DNS and DHCP products available from various vendors, most traditional solutions still require significant effort on the part of network administrators to keep track of the necessary TCP/IP information, to avoid addressing conflicts, and to troubleshoot configuration errors.

This AppNote introduces Novell's DNS/DHCP Services software, a new product in the Border Services family of products, that integrates both DNS and DHCP into Novell Directory Services (NDS) to facilitate automated management of enterprise-wide IP addresses, host names, and configuration. Following a brief technology primer and overview of how Novell's DNS/DHCP Services provides DNS and DHCP services in a NetWare environment, this AppNote describes how Novell has implemented the product internally to ease the migration to a more pervasive TCP/IP network environment. This information is targeted to IT executives, network support engineers, and system administrators who are interested in reaping the benefits that Novell's NDS and DNS/DHCP Services provide.

DNS/DHCP Technology Primer

To begin, it is helpful to review how traditional DNS and DHCP solutions work. It is assumed that the reader is familiar with the basics of TCP/IP, DNS, and DHCP, as a detailed discussion of these technologies is beyond the scope of this AppNote. If you need background information relating to DNS and DHCP, we recommend the following resources:

  • DNS and BIND by Paul Albitz and Cricket Lui (O'Reilly & Associates, Inc., 1997, ISBN 1565922360). Considered by many to be the definitive work on DNS, this book sets de facto standards in almost every area of DNS.

  • "Installing and Configuring NetWare TCP/IP on a NetWare 3.11 Server", Novell AppNotes, March 1993. Although written back in the days of NetWare 3.11, this AppNote contains a general discussion of IP addressing that is still applicable today.

  • DNS Resources Directory at http://www.dns.net/dnsrd/. This site contains links to many DNS-related documents on the Web.

  • DHCP FAQ at http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html. This is a fairly comprehensive FAQ that answers most general questions about DHCP.

It is also helpful to understand the basics of Novell Directory Services operation and design. Recommended resources for this include:

  • "Design Rules for NDS Replica Placement", Novell AppNotes, January 1997

  • "Universal Guidelines for NDS Tree Design", Novell AppNotes, April 1996

  • "Ten Proven Techniques for Improving NDS Performance and Reliability", Novell AppNotes, April 1996

  • "Management Procedures for Directory Services in NetWare", Novell AppNotes, March 1994

The Role of DNS

On a TCP/IP network, each device must have a unique address assigned to it. The syntax for this address is currently specified by the Internet Protocol (IP) as four decimal numbers in the range 0 - 255, separated by periods, as in 127.0.0.1. Computers on the Internet or on corporate intranets use these numerical addresses to communicate with each other.

Of course, humans prefer to use more intuitive names when working with resources on a network. That's where the Domain Name System, or DNS, comes into play. DNS is a distributed database system that provides host name-to-IP resource mapping. The IP resource most frequently needed is the IP address, but DNS can also provide other information that computers on a TCP/IP-based internetwork need to locate other computers. The benefit for humans is that DNS translates between numerical IP addresses and the corresponding host names so that we don't have to concern ourselves with the numerical addresses of resources we know the names for, such as www.novell.com.

Domains and Host Names. Anyone who has accessed resources on the Internet is familiar with DNS domains and host names. DNS works from an inverted tree structure, much like the NDS tree structure used in intraNetWare/NetWare 4.x networks. Branching downward from the single entity at the top of the DNS structure are several top-level domains that divide the hierarchy into various categories. Commercial organizations use the .com domain; educational organizations use the .edu domain; governmental agencies use the .gov domain, and so on. These domains can be further divided into subdomains representing individual organizations or divisions within the domain.

For example, Novell has created a subdomain under the .com top-level domain, identified on the Internet as novell.com. Within Novell, this domain is further divided into subdomains such as provo.novell.com, sjf.novell.com, and ukb.novell.com (see Figure 1).

Figure 1: Sample DNS hierarchy.

Each computer that uses DNS is given a DNS host name which represents that computer's position within the DNS hierarchy. For example, the host name for host1 in Figure 1 above is host1.provo.novell.com. An IP address would also be assigned to the host.

Note: In this AppNote, the term host refers to a network device that requires an IP address and that might have a host name.

Domain Delegation and Zones. No single entity can possibly maintain a database of all the host names and addresses on a large network such as the Internet. For this reason, DNS allows the administrative responsibility for a particular group of domains and subdomains to be delegated to organizations which have authority over their portion of the DNS hierarchy. The set of DNS domains and subdomains that an organization is given authority over is called a zone. All host information for a zone is maintained by the organization's network administrator in a single, authoritative database. For example, the IS department at Novell is responsible for the DNS information for the zone comprised of novell.com and its subdomains.

DNS Name Servers. The name service part of DNS is based on a client-server mechanism in which clients query name servers for host address information. Each DNS zone has a single master name server that maintains a database of authoritative information about hosts in that zone. In addition to local host information, name servers maintain information about how to contact other name servers. If a name server does not have information about a particular domain, it relays the request to other name servers up or down the domain hierarchy until it receives an authoritative answer for the client's query.

A DNS name server can be either a primary or a secondary name server.

  • A primary name server is one which gets its DNS entries from a file on its local hard disk. It is said to be "authoritative" for a particular zone because it does not need to double-check its DNS information with any other name servers in the zone. It pulls the host name and address information directly from the records on its disk, which are updated and maintained by the domain administrator as changes occur. There is only one primary name server per zone.

  • Secondary name servers have read-only copies of the primary name server's DNS database. When a secondary name server starts up, it contacts the primary name server and requests a complete copy of the primary's DNS database. After this initial copy, the secondary periodically connects to the primary and downloads the latest DNS information. This process, called a zone transfer, ensures that DNS information changed on the primary name server is replicated across the system. Zone transfers are usually timed to occur every 2 to 4 hours. A secondary name server can receive DNS update information from more than one primary.

Note: A third form of DNS server, called a caching-only server, will be introduced later in this AppNote.

The Resolver. Another main component of DNS is the resolver. This is software which is loaded on the client and which "knows" how to contact a DNS name server. For Windows-based clients, the resolver is usually implemented as a Dynamic Link Library (DLL) or some other form of shared library. The issue of which name servers to ask in what order is an important part of TCP/IP client configuration. If the specified local DNS name server does not have the information requested by the client, similar resolver software in the server takes over and asks another DNS name server for help. This process is known as recursive resolution.

The DNS Database. The DNS database is made up of Resource Records (RRs) which contain the host information maintained by the name servers. Different types of records contain different types of host information. For example, some of the more common types of RRs are listed below:

  • Address (A)-- Links a host name to an IP address.

  • Pointer (PTR) -- Used in special domains to point to some other location in the domain name space. Mainly used for reverse lookups in which the resolver requests a host name by providing an IP address.

  • Name server (NS)-- Binds a domain name with a host name for a specific name server. The DNS zone must contain NS records for each primary and secondary name server in the zone.

  • Start of Authority (SOA)-- Indicates the start of authority for the zone. The zone must contain one SOA record specifying its zone of authority.

  • Canonical name (CNAME)-- Provides a second name for a domain name. The actual owner name is an alias.

  • Mail exchange (MX)-- Identifies a mail exchange server for a DNS domain to be able to accept e-mail from the Internet.

Traditional DNS Implementation. DNS is typically set up by entering all of the Resource Records for a zone into a text-based master file, which is maintained on the zone's primary name server. These files might have hundreds or thousands of entries for the different types of resources, such as users' addresses, hosts, name servers, mail servers, and pointers to other resources.

Figure 2 represents a traditional DNS implementation strategy with primary and secondary DNS name servers in a multiple zone configuration.

Figure 2: Traditional DNS structure.

In this example, the novell.com zone has a master DNS name server that handles queries about the entities within it. The master DNS server provides DNS name service for two zones: novell.com and other.com. Each of these zones has a secondary DNS server to provide backup support. When updates are made to the master name server, the entire contents of the DNS database must be copied to each of the secondary name servers through zone transfers.

Because DNS was developed for use on the Internet, it has an extremely fault-tolerant design. As a result, it is difficult to break. Yet users seem to encounter "Host Name not found" errors quite frequently, often accompanied by wording to the effect that the requested service does not have a DNS entry. In some cases this is not the problem at all, but rather a name server higher up in the hierarchy is overloaded and a timeout occurs before it can respond. The tendency to report the "Host Name not found" error as the default response to a wide variety of anomalous behavior makes troubleshooting DNS problems a frustrating task.

The Role of DHCP

One of the biggest challenges in a TCP/IP network is assigning IP addresses and other configuration parameters for each device. It is important that IP addresses be unique across a network, because if two devices on the same network try to use the same IP address, one of them will be denied access. DHCP automatically allocates reusable network addresses, helping administrators make more efficient use of limited IP address resources.

When discussing DHCP, it is important to distinguish between static and dynamic IP addresses:

  • A static address is an IP address that is entered directly into the DNS database and which does not change once it is assigned to a host machine. Most network services (for example, file servers and Web servers) will usually have static addresses as this eases administration and lowers overhead on the network, thus increasing reliability.

  • A dynamic address is an IP address that is dynamically assigned to a client workstation on startup. Using dynamic addresses dramatically reduces administration on the network because it eliminates the need to constantly update the DNS manually. Typically this method is only used for client devices.

In the past, dynamic IP addresses were allocated through a service called the Bootstrap Protocol or BOOTP, which was designed for manual configuration of the host information in a server database. Now TCP/IP networks are rapidly moving to Dynamic Host Configuration Protocol (DHCP) servers to hand out addresses to workstations.

There are three basic ways IP addresses can be allocated on a network:

  • Manual allocation. A network administrator keeps a manually-updated DNS database and assigns addresses as required. The addresses are manually entered at each client computer.

  • Automated allocation. A host assigns an IP address to a client on a permanent basis; the lease doesn't expire. The automation is usually linked to a centrally-administered DNS database that keeps track of addresses.

  • Dynamic allocation. A host assigns an IP address to a client for a limited period of time or until the client states that it no longer needs the address and gives it back.

Dynamic Host Configuration Protocol (DHCP) uses this third method to provide IP addresses and configuration parameters dynamically to clients and services, although it does support manual (static) allocation and dynamic BOOTP allocation as well.

Like DNS, DHCP is based on a client-server model. DHCP consists of two components: a mechanism for allocating network addresses, and a protocol for delivering specific configuration parameters from a DHCP server to a client. The DHCP server allocates network addresses and delivers configuration parameters to clients which request this information when they start up and attach to the network.

Note: A client can be any device on the network, from a user's workstation or portable computer running Windows 95/NT/3.x or DOS, to printers and even servers.

DHCP Address Allocation. DHCP servers hold a "pool" of addresses which they can hand out. This pool is typically formed by collecting all of the free IP addresses within an organization's allocated range (the others being statically assigned) and relinquishing the dynamic allocation process to a DHCP server. The free addresses are entered into a DHCP server, where they become the address pool that the DHCP server uses to assign addresses to clients. Once the DHCP server allocates an address to a client, it guarantees not to give that address to any another client within a specified time. Additionally, the DHCP server tries to return the same IP address to the client each time it requests an address.

Each dynamically-assigned IP address has a lease time and a renew time. Lease time is the length of time that the client may use the assigned address before having to check with the server to see if the address is still valid. Renew time is the interval after which the client checks with the DHCP server to renew the existing lease. It is expressed as a percentage of the lease time. For example, if a client has an 8 hour lease time with a 75% renew time, the client will check after 6 hours to see if it can keep the address for another 8 hours. A given DHCP address can thus remain standard on a client instead of changing at the end of each lease time.

DHCP's dynamic allocation method has a number of advantages over manually entering addresses:

  • It eliminates the need to visit each desktop for IP address maintenance.

  • It reduces support time due to standardized IP numbering schemes.

  • It improves control over access to DNS resources, since the DHCP server can assign which DNS name server to use.

Typical Implementations of DHCP. Many businesses with TCP/IP networks use DHCP because it reduces network management overhead and helps them conserve on limited IP addresses. Internet Service Providers (ISPs) often use DHCP for similar reasons. DHCP is also useful for mobile employees who travel between offices, as it allows them to connect to the network in each new location without having to involve IS staff. DHCP is used extensively on "private" networks where address conflicts are not an issue because the computers are not connected to the Internet.

The Role of Dynamic DNS (DDNS)

DHCP is "dynamic" because a DHCP server can assign available IP addresses to clients automatically in response to their requests. However, that means a particular client that has a particular host name won't always have the same address. DNS servers are supposed to provide the current address for any host name sent to them by a resolver, but they must be manually updated with changes in address assignment. This presents a problem--no matter how often or how fast an administrator updates the DNS database, there's always a good chance that the database will be out of sync with reality because of the dynamic nature of DHCP.

Dynamic DNS (DDNS) provides a way for DNS databases to be instantly notified and updated with address assignments made by DHCP servers. One way to achieve DDNS is for the DHCP server to modify and/or delete the appropriate RRs (A and PTR) in the DNS database so that the DNS servers always know which IP address belongs to which host.

Problems with Traditional DNS/DHCP Solutions

While the advantages of using DNS and DHCP in the TCP/IP environment are considerable, traditional solutions have several drawbacks that limit their effectiveness. Some of the main limitations are summarized below.

Tracking IP Address Usage Is Difficult

IP addresses are a scarce resource. Under the current IP specification (IPv4), a fixed number of addresses are available for use worldwide. From this base pool, individual organizations are allocated a specific range of addresses which they can assign for their own internal use without causing conflicts or routing problems when connected to the Internet. Although the upcoming revision of IP (IPv6) will greatly expand the pool of available IP addresses, the limitations of IPv4 will continue to be a concern for quite some time.

While traditional DNS/DHCP solutions help automate the process of assigning IP addresses, they lack the ability to manage individual DNS databases together to efficiently track address usage across an entire enterprise. Whenever a new address is assigned to a device, the change must be made on the primary DNS server and then copied over wholesale along with the entire DNS database to the secondary DNS servers. In this scenario, the primary DNS servers are the points of administration, which constrains the physical location of these servers and often requires considerable TCP/IP expertise to maintain the system.

Configuration of TCP/IP Nodes Is Laborious

Any way you look at it, TCP/IP requires a great deal of configuration. In addition to IP addresses, many devices require information such as Host and Domain Names, IP Router or Gateway, DNS Server Name, and so on. Updating and maintaining this configuration information on even a small network is tedious, time consuming, and error prone. DHCP helps a lot in automating the configuration process, but many implementations still require a significant amount of administrator effort to keep everything in synch. Moreover, some types of devices require static IP addresses, which must be maintained manually.

Name and Address Services Are Not Integrated

As addresses are assigned to individual devices, this information needs to be incorporated into DNS so the new addresses can be resolved to the corresponding host names. This should be done regardless of whether the host name is assigned to the node dynamically, or the device provides its own name that is then bound to the assigned address. Since host names and addresses are merely different forms of the same essential information, it only makes sense that services which manage names and addresses be integrated. Yet in many existing implementations there are no ties between DNS and DHCP.

Fault Tolerance Must Be Provided

Fault tolerance and redundancy are crucial to the success of DNS and DHCP. Once a network has been moved over to DHCP, it is critical that DHCP services be provided without interruption. If the service is lost, every machine on the network will lose its IP address as its lease expires and none will be able to connect to anything (services, printers, other networks, and so on). In DNS, redundancy is provided in the form of secondary DNS servers. If a primary DNS server goes down, you can change a secondary into a primary very quickly. Backup servers are also used on the DHCP side.

Need Compatibility and Interoperability Across Heterogeneous Systems

Since most customers have a wide range of systems for both clients and servers, it is important to have solutions that support a heterogeneous environment. In particular, many sites have client workstations that are still using BOOTP, the predecessor to DHCP, and thus require a DHCP server that can assign addresses to both BOOTP and DHCP clients.

Interoperability is also important for DNS, since most companies already have DNS servers installed. When a new DNS product is deployed, it is very helpful to be able to transfer existing DNS configurations between the old and the new systems. This not only reduces the effort required for migrating to a new system, it also allows that migration to take place at the customer's own pace.

Note: Since TCP/IP networks have grown out of the Unix environment, most DNS name servers are currently running on Unix machines. The most popular DNS program for Unix is called BIND (Berkeley Internet Name Domain). In fact, BIND is so pervasive that compatibility with it is considered essential for any competitive DNS product. Novell's DNS product is compatible with BIND Version 4.9.6 as it is the most widely used version of the program today.

Novell's New Solution: DNS/DHCP Services

To simplify the configuration and management of DNS and DHCP, Novell has developed a new product called DNS/DHCP Services. Whereas Novell's previous DNS product used Btrieve as its database for holding configuration information, the new DNS software integrates DNS into NDS. Integrating DNS with NDS greatly simplifies network management by enabling you to enter all configuration information into one distributed database, where it is then replicated just like any other data in NDS.

By integrating DNS into NDS, Novell has shifted the concept of a primary or secondary zone away from the server to the zone itself. DNS zone data is stored within NDS and is replicated just like any other data in the tree. This approach allows changes to be made from anywhere in the network through NDS, which is not tied to one server. Once you configure the zone, the data is available to any of the Novell DNS servers you choose to make authoritative for the zone. In essence, you create "virtual" DNS servers in which the DNS master records themselves reside in the replicated database of NDS. This eliminates the single point of administration inherent in traditional server-centric solutions.

The Designated Server

While all Novell servers can see DNS data once it gets into the Directory through NDS replication, only one server needs to do a zone transfer to get data into the Directory. The server assigned to this function is called the designated server. The designated server is a server identified by the network administrator to perform certain tasks that only need to be done once. These tasks vary depending on whether the Novell DNS server for the zone is acting as a primary or a secondary:

  • For a secondary zone, the designated server is responsible for requesting a zone transfer of data from the external primary name server. The designated server determines what data has changed for a zone and then makes updates to NDS so that other servers are aware of the changes. For a secondary, we refer to the designated server as the Zone server.

  • For a primary zone, one of the designated server's tasks is to make changes in the zone as a result of Dynamic DNS updates from DHCP (adding and deleting Resource Records, updating the zone's serial number, and so on). For a primary, we refer to the designated server as the Dynamic DNS server.

Figure 3 illustrates a simple configuration of Novell DNS servers in primary and secondary zones within NDS.

Figure 3: Novell DNS servers acting as primaries.

In this example there are two zones for which NDS is primary. Any of the Novell DNS servers assigned to the zone are able to respond to queries for the zones. For each zone, one server is designated by the administrator to act as the designated server. In our example Server 1 is the designated server for Zone 1, Server 2 is the designated server for Zone 2, and Server 3 is the designated server for the secondary zone called Foreign Zone. Server 3 wil occasionally request zone transfers from the foreign server and place the modified zone data into NDS, where any of the Novell servers can respond to queries for it.

NDS Extensions to Support DNS and DHCP

To accomplish its integration with NDS, Novell's DNS/DHCP extends the NDS schema, creating new NDS objects to represent the necessary DNS and DHCP information. These new objects are listed in the table below.


New NDS Object
Description

DNS/DHCP Global Objects

DNS/DHCP Group

A standard NDS group object used to grant DNS and DHCP servers the necessary rights to other data within the NDS tree.

DNS/DHCP Locator

An object that contains global defaults, DHCP options, and lists of all DHCP and DNS servers, subnets, and zones in the NDS tree.

DNS-Related Objects

DNS Server

A leaf object that stores DNS server configuration parameters.

DNS Zone

An NDS container object that holds all the data for a single DNS zone. It is the first level of the DNS zone description.

DNS Resource Record Set (RRSet)

A leaf object located inside a DNS Zone object that represents an individual domain name within the zone and contains RR information.

DHCP-Related Objects

DHCP Server

A leaf object that represents the DHCP server and contains a listing of the subnet ranges this DHCP server is servicing. It also contains all server-specific configuration and policy information.

Subnet Pool

An object that provides support for multiple subnets through a DHCP or BOOTP forwarder by identifying a pool of subnets for assigning addresses across a WAN or remote LAN connection.

Subnet

A container object that represents the most fundamental division within DHCP: a subnet. It acts as a container object for the IP Address and Address Range objects. It also stores specific DHCP options and configuration parameters that apply to the entire subnet and override global options.

Address Range

An object primarily used to denote a range of addresses. It could represent a pool of addresses for dynamic assignment, or a range of addresses to be excluded from address assignment. There can be multiple Address Range objects under a Subnet object.

IP Address

A leaf object which represents a single IP address. This object must include an address number and an assignment type (manual, automatic, dynamic, or excluded).

Figure 4 shows a representation of these new NDS objects as they might be set up within a DNS zone.

Figure 4: Example of NDS objects within a DNS Zone.

Benefits of Novell's DNS/DHCP

To recap, here is a summary of the major benefits provided by Novell's DNS/DHCP Services.

Integration with NDS Simplifies IP Name/Address Management. By storing DNS hostnames and DHCP-administered IP addresses and options in NDS, Novell's DNS/DHCP provides access to all of this information in a replicated, distributed database. The DNS and DHCP data is thus available at multiple locations in the network, creating "virtual" DNS and DHCP servers within NDS. This eliminates the single point of failure that traditional server-centric solutions provide. By eliminating the need to manage and synchronize separate DNS and DHCP databases, DNS/DHCP Services greatly simplifies network management and significantly reduces the cost of administering IP addresses.

Tight integration with NDS provides for additional benefits. By using the inherited rights feature of NDS, management of specific subnets and domains can be either distributed or centralized, providing for a policy-based approach to management at an organizational or departmental level. Thus, you can free up highly specialized support personnel for other tasks, moving DNS and DHCP servers closer to the users that need them and delegating the management of specific subnets and domains to local help desk personnel.

Finally, you do not need to initiate server-to-server zone transfers that are typical when updating secondary servers from their primary servers. When you update DNS data, it is replicated across the network and is available to any Novell DNS server acting in a secondary role.

Dynamic Interaction Between DNS and DHCP. Novell's DNS/DHCP supports Dynamic DNS (DDNS) to update DNS with information about addresses assigned and rescinded. DDNS is a system whereby DHCP services are combined with DNS. Every time an IP address is dynamically assigned to adevice on the network, the DNS is automatically updated to allow resolution to that device. The advantages of DDNS are that users gain easy access to resources using DNS. For the administrator, this eliminates the error-prone and time consuming process of manually assigning and managing IP addresses.

DNS/DHCP Services dynamically assigns IP addresses from a pool of available subnet addresses, eliminating network problems associated with duplicate IP addresses. You can also configure the program to ping an address before assigning it to verify that no other device is using that address.

Supports Many Critical DHCP Options. DNS/DHCP Services enables you to centrally configure the address assignment policy so it meets your organization's needs. DHCP policies can be set at the enterprise, subnet, or individual client level. For example, you can select the lease time that all DHCP clients are permitted to use an IP address. By choosing a short lease time, you can enable a large number of clients to use a limited number of IP addresses, reducing the need for additional (and scarce) addresses. Also, by recycling "old" addresses, you don't lose track of IP numbers through static or outdated assignments that can occur, for example, when a department is relocated from one building to another.

Additional DHCP and vendor options that can be assigned at lease time include:

  • Domain name

  • NetWare/IP settings

  • Service Location Protocol (SLP) options

  • NetBIOS name server

  • NIS/NIS+ domains/servers

  • Subnet masks

  • For NetWare 5: NDS Servers, Tree Name, and Context

  • User-defined option tags

For specific clients, you have the option to assign a static IP address that can also be associated with an NDS user name. Finally, you can restrict specific workstations or groups to a certain address range. Or, you can create and maintain a hardware exclusion list through which you can deny DHCP service to certain devices by their MAC addresses.

Increased Flexibility. When used with a traditional DNS server, the Novell DNS server can act as either a master or secondary DNS server. As a master server, it can transfer data into NDS from non-NDS secondary servers. Or, the Novell DNS server can act as a secondary DNS server and transfer data into NDS from a non-NDS master server. This allows you to make available a superset of DNS information directly within NDS. DNS/DHCP Services supports multihoming and forwarding, can function as a cache-only server, and can be authoritative for multiple domains, making it ideal for Internet services providers and for large, geographically dispersed organizations.

Improved Management Console. DNS/DHCP comes with a new Java-based management console for configuring and managing the NDS objects related to DNS and DHCP. It can be run as a standalone console at a client workstation, or it can be accessed from the Tools menu of the NetWare Administrator utility. You can use the console to set how often you want zone transfers between NDS and non-NDS DNS servers to occur. It also enables you to view an audit trail generated by the server, so you can track such information as address additions, deletions, and rejections (with the corresponding MAC addresses).

Import/Export Capabilities. With Novell's DNS/DHCP, DNS data can be read in from a BIND 4.9.6-compatible master file to populate NDS. DNS data can also be exported out of NDS into BIND 4.9.6 master file format. This aids in upgrading from or interoperating with BIND 4.9.6-compatible implementations of DNS. Likewise, DHCP data can be imported from an existing Novell DHCP Server 2.0 DHCPTAB file or from a BOOTPTAB file (for Novell BOOTP). DHCP information can also be extracted from NDS and saved in a text file that can later be imported into other DHCP products.

Compatibility with Industry Standards. The DNS software in Novell DNS/DHCP is based on BIND 4.9.6 and supports IPv6 Resource Records. See Appendix Aof this AppNote for a list of supported IETF standards.

Case Study: DNS and DHCP Implementation within Novell

The previous DNS system within Novell has been in place since Novell started using TCP/IP in the 1980s, It grew organically with the company's network to eventually support thousands of devices. Figure 5 shows how the previous DNS service was implemented, with eight primary DNS servers located at various sites around the world.

Figure 5: For Novell's original intranet, primary DNS servers were located at each major site.

Novell deployed DHCP on a limited basis with six DHCP servers located at various sites within the United States. All IP addresses were registered in the DNS via a custom-built "IP Robot." All service-providing devices on the network had statically-assigned addresses; DHCP-assigned addresses were limited to user machines.

In Europe and the Middle East, IP addresses and DNS information were supplied to client machines only. All services were given static addresses which were entered manually and kept track of using IP Assignment web pages. Each site had an independent DHCP server; addresses were not handed out across WAN links. In other Novell locations, DNS rather than DHCP was used to track assigned addresses.

The previous DNS system within Novell was housed on several primary name servers spread across various regions around the world. These servers were running a variety of Unix flavors and thus were administered by a number of people with varying levels of Unix expertise.

Thanks to its distributed design and support for multiple platforms, the current DNS system at Novell had been working fairly well. During the day, large primaries like ns.novell.com routinely handled up to 80 requests per second without complaint. The biggest problem with this DNS system was that it had become extremely resource-intensive to maintain. Over time, the day-to-day administration of the DNS had shifted away from the operations teams into the hands of a few specialists. The smooth running of this system rested largely on the shoulders of a few dedicated administrators who spent a considerable amount of time supporting the administration and design of the DNS. Although various tools were written to ease DNS management, they were mainly useful only for distributing new addresses. Any additional tasks such as removing addresses, changing mail entries, changing delegations, or creating reports on domains had to be done manually by one of the primary administrators.

Other drawbacks to this implementation reflected some of the same issues that are valid for many other, traditional DNS/DHCP products:

  • All changes to the DNS information had to be made at the primary server.

  • The DHCP program had no ties to DNS.

  • Static IP addresses for servers and other service-providing devices had to be maintained manually.

The New DNS/DHCP Implementation at Novell

To overcome some of the limitations in the traditional DNS/DHCP implementation and take advantage of the many benefits provided by DNS/DHCP services, Novell recently revamped its internal DNS/DHCP strategy. The redesigned system, which is being implemented in several phases, promises to provide easier management, better performance, and increased reliability across the company.

Figure 6 outlines the redesign of Novell's internal DNS system for Phase One of the project.

Figure 6: Logical design structure of the redesigned intranet (Phase One).

Key Improvements

Following are some of the key improvements and considerations made in this network redesign.

Standardized Hardware and Software Platforms. Although Novell's previous Unix-based solutions were working, the IS&T team recognized that advanced Unix administration skills were becoming scarce at the help desk level. In addition, Novell had made a strategic decision to move all internal systems onto Intel-based platforms. The new DNS system therefore retains the previous BIND solution only on the three primary name servers, which are identically-configured Intel-based servers running UnixWare. (Phase Two calls for the elimination of the BIND solutions and UnixWare in favor of Novell's DNS/DHCP and NetWare.)

Secondary name servers have been installed in each of Novell's geographical locations. The secondaries are all running Novell's DNS/DHCP (along with other Novell software, as described below) to reduce the load on the primaries and increase system reliability. The consistent hardware and software setups make it easier to maintain the system and diagnose any problems that arise.

Reduced Load on Primary Name Servers. The three primary name servers are used only by secondaries and service-providing devices on the network. Client workstations access the closest secondary name server for DNS and DHCP information. This reduces the load on the primaries and improves overall DNS performance for internal resources and commonly-accessed external resources. Having a smaller number of primaries simplifies administration and troubleshooting of DNS, while the use of more secondaries increases the resilience of the system by providing redundancy and local access.

In addition to these primaries, a new ns.novell.com name server (along with a backup) has been set up to act as the primary for all registered domains worldwide. This also eases administration and ensures consistency in handling of all externally-registered addresses. Although this server appears to the outside world to be outside of the corporate intranet, it is actually located in-house and is made accessible via "peepholes" in the firewall.

Combining Services on Secondary Servers. In developing this redesign, Novell's IS&T team envisioned the possibility of having the secondary DNS function be part of a so-called "IP Services" server. Such a server supports the following services:

  • Secondary DNS

  • DHCP (for local networks)

  • BorderManager FastCache (for Web Server caching)

  • Multiprotocol routing and remote access (for WAN and mobile users)

  • Web Server (intranet)

This conglomerate server is designed to provide all IP-related services that are required for a Tier Three (0 to 50 users) or Tier Two (50 to 300 users) site with minimal hardware. Combining secondary DNS and DHCP services on the same server also allows for easier integration between DNS and DHCP.

Secondaries at Tier Two sites are configured for regular zone transfers (every 2 to 4 hours), while secondaries at Tier Three sites are configured to be caching-only servers. This reduces bandwidth demands and administrative overhead, but still improves local performance.

DHCP services have not been made available across WAN links for a variety of reasons relating to the performance and stability of the WAN links. To ensure reliable service, the team decided to place a local DHCP server at every physical site.

Improved Integration of DNS and DHCP. All servers have been set up to support Dynamic DNS. When DNS information is created as the servers hand out host addresses, it is automatically reflected in DHCP. The servers also act as DNS secondaries for all clients receiving DHCP addresses from them.

Easier Regional Management. Thanks to the improved management console and DNS/DHCP Service's use of NDS, routine management of the DNS system no longer requires advanced Unix skills. Local operations people can now handle day-to-day tasks such as adding and removing DNS entries, creating reports, and first-level debugging of problems using defined criteria. Advanced management issues relating to delegation, mail system records, or fault detection that cannot be fixed at a secondary site are handled by second-level administrators at primary sites.

Providing DHCP Redundancy

Novell's previous DHCP Version 2 implementation used two DHCP servers on each site for redundancy. The design provided redundancy by splitting each network range across the two servers. This way the servers could both provide addresses to a given subnet, the theory being that if one server is down or out of addresses, the other could take over servicing the requests.

The new implementation with DNS/DHCP Services uses a similar design, providing redundancy by splitting the DHCP address pools across two DHCP servers. As new address ranges were made available on the routers, they were also entered on the DHCP servers. Thus dynamic addresses were available on the new subnets from day one.

Import of Existing IP Addresses and DNS Information

Manually-assigned addresses were migrated from the current BIND system on Unix to the Novell product on a subnet-by-subnet basis. This information was then "primaried" back to the existing BIND system. Once this process is complete, the BIND system will ultimately be turned off.

Each site's IS&T operations team is responsible to plan the aggressive conversion of the desktops from using manually-assigned IP addresses to using DHCP. This conversion means that every client machine on the network needs to be reconfigured to switch it from a manually-assigned IP and DNS address to a dynamic one. To speed up this process, IS&T prepared and distributed to users step-by-step documentation explaining how to change a workstation from manual to dynamic addressing. In areas where users are not comfortable making this change themselves, IS&T is using Novell's Z.E.N. Works, which includes the Novell Application Launcher (NAL) and a remote workstation console, to automate this task.

The end result is a complete devolution of IP numbering and DNS management from a centralized model to a distributed model where each site is responsible not only for its IP address pool but also for its DNS information.

Summary

This AppNote has described the new DNS/DHCP Services software and how it has helped provide Novell with an improved DNS and an easier method of administering IP addresses. This technology will help form the backbone of a reliable TCP/IP-only infrastructure across Novell's internal systems. With DNS/DHCP Services, the IS&T team will be deploying a state-of-the-art NDS-based solution that showcases the benefits of Novell's TCP/IP networking solutions. These same benefits are available to our customers, regardless of the size of their networks.

Appendix A: Supported Standards

The DNS software supports the following standards:


RFC 819RFC 920RFC 974RFC 1032RFC 1033RFC 1034RFC 1035RFC 1036RFC 1101RFC 1122RFC 1123RFC 1183RFC 1535RFC 1536RFC 1537RFC 1591RFC 1597RFC 1627RFC 1713RFC 1884RFC 1886RFC 1912RFC 2010 RFC 2052

Domain Naming Convention for Internet User ApplicationsDomain RequirementsMail Routing and Domain SystemDomain Administrators Guild Domain Administrators Operations GuideDomain Names - Concepts and FacilitiesDomain Names - Implementation and SpecificationStandard for Interchange of USENET MessagesDNS Encoding of Network Names and other TypesRequirements for Internet Hosts - Communication LayersRequirements for Internet Hosts - Application and SupportNew DNS RR DefinitionsA Security Problem and Proposed Correction with Widely Deployed DNS SoftwareCommon DNS Implementation Errors and Suggested FixesCommon DNS Data File Configuration ErrorDomain Name System Structure and DelegationAddress Allocation for Private InternetsNetwork 10 Considered Harmful (Some Practices Shouldn't Be Codified)Tools for DNS DebuggingIP Version 6 Addressing ArchitectureDNS Extensions to Support IP Version 6Common DNS Operations and Configurations ErrorsOperational Criteria for Root Name Servers A DNS RR for Specifying the Location of Services (DNS SRV)

The DHCP software support the following standards:


RFC 2131RFC 2132RFC 2241RFC 2242

Dynamic Host Configuration ProtocolDHCP Options and BOOTP Vendor ExtensionsDHCP Options for Novell Directory ServicesNetWare/IP Domain Name and Information

For BOOTP, the product supports the following standards:


RFC 1497RFC 1534RFC 1542

BOOTP Vendor Information ExtensionsInteroperation Between DHCP and BOOTPClarifications and Extensions for the Bootstrap Protocol

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates