Novell is now a part of Micro Focus

Overview of Novell DNS/DHCP Services

Articles and Tips: article

01 Aug 1998


Provides an overview Novell DNS/DHCP Services, standards-based software that integrates the Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP) into Novell Directory Services (NDS). DNS/DHCP Services extends the NDS schema and enables you to centrally administer and manage IP addresses and host names through NDS. Also discusses the Dynamic DNS feature.

Introduction

Novell DNS/DHCP Services is standards-based software that integrates the Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP) into Novell Directory Services (NDS). The DNS server maps and resolves network device IP addresses to user-friendly host names. DHCP is a client/server protocol that automatically assigns and tracks IP addresses and other configuration data in network devices. DNS/DHCP Services also supports Dynamic DNS (DDNS), which dynamically updates the host name database with new IP addresses. DNS/DHCP Services extends the NDS schema and enables you to centrally administer and manage IP addresses and host names through NDS. It also includes the Java DNS/DHCP Management Console that enables you to easily configure and manage your DNS and DHCP services.

DNS/DHCP Services extends the NDS database schema to include DNS host names and DHCP- administered IP addresses, giving you access to all your DNS/DHCP information in a replicated, distributed database. There is no single point of failure in this highly fault-tolerant and secure environment. This kind of IP address management can reduce the cost of administering IP addresses by as much as 83 percent, according to research conducted by Gartner Group, Inc.

DNS/DHCP Services automatically assigns IP addresses and other configuration information to hosts. When the IP address of a host is changed, its DNS information is dynamically updated by DDNS to associate the existing host name with the new IP address. DNS/DHCP Services dynamically assigns IP addresses from a pool of available subnet addresses, eliminating network problems associated with duplicate IP addresses.

You can set DHCP options at the enterprise, subnet, or client level. For example, you can select the amount of time (known as "lease time") that a DHCP client is permitted to use an IP address. By choosing short lease times, you can enable a large number of clients to use a limited number of IP addresses. You can also assign a static IP address and configuration to a specific client using its media access control (MAC) address.

The NDS DNS server can act as either a primary or secondary DNS server when used with a non-NDS DNS server. As a primary, it can transfer data into NDS from non-NDS secondary servers. Or, as a secondary DNS server it can transfer data into NDS from a non-NDS primary server.

DNS/DHCP Services includes a Java Management Console, with a graphical user interface, which you can use to monitor, configure, and manage the DNS and DHCP services in NDS. The Console enables you to easily import your existing DNS and DHCP data into NDS, whether that data is located in an existing Novell DHCP Server 2.0 file, a Novell BOOTP file, or a BIND DNS master file.

The application 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).

The Domain Name System (DNS)

Host names have been a part of the Internet and its progenitors since the earliest days. For years Internet computers located each other by looking up host names in a database that had to be downloaded on a regular basis from the Network Information Center. But before too long the flat-file host-name database began to be unwieldy, and replicating it around the network too cumbersome. Attempts to solve that problem led to the development of DNS, the Internet's hierarchical naming scheme.

DNS is basically just a database that matches up the names of computers or other network devices to their IP addresses and other data. DNS has two parts the hierarchy and the name service. The DNS hierarchy, also called the domain name space, specifies a host's domain, that is, where it is in relation to other hosts on the network. The hierarchy can be thought of as an upside-down tree. The DNS tree has a single domain at its root called the root domain. Below the root domain are the top-level domains. These are the Internet's familiar .com, .edu, .org, and so on. Below the top-level domains, the domain name space is further divided into subdomains representing individual organizations. A host's domain name is simply a list of all domains in the path from the host back to the root, for example, support.novell.com.

DNS's name service component is the part that actually maps the host name to the IP address so computers can locate each other on a network. The name service uses a client and server setup in which client programs (resolvers) query one or more name servers for host address information. If a name server doesn't have information about a particular domain, the name server relays the request to other name servers up or down the domain hierarchy until it receives an authoritative answer to the client's query.

A group of domains and subdomains for which an organization has authority is called a zone. In traditional DNS, the one name server that maintains an authoritative database for an entire zone is called the primary name server, and the domain administrator updates it with host names and addresses as changes occur. Secondary name servers, which provide redundancy and load balancing for a zone, contain read-only copies of the primary name server's DNS database. Periodically they receive a new copy of the primary's DNS database through a zone transfer.

DNS databases contain numerous blocks of data called resource records (RRs). The following RRs are among the most important for standard DNS:

  • Address (A) records provide the IP address for the zone.

  • Name Server (NS) records bind a domain name with a host name for a specific name server.

  • Start of Authority (SOA) records specify a server's zone of authority.

  • Canonical Name (CNAME) records specify the canonical or primary name for the owner.

  • Pointer (PTR) records point to other records and are used for reverse lookup, i.e., looking up a domain name when the IP address is known.

The Dynamic Host Configuration Protocol (DHCP)

If you want a computer or some other device to function on an IP network, you must configure it with a number of "IP options." These options are small but important tidbits of data, such as the client's own domain name and IP address, the DNS server's IP address, the subnet mask, and so on. A computer must know these things in order to interact with other network devices.

In the past, IP addresses have been assigned through a service called the Bootstrap Protocol (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 that automatically hand out addresses and other parameters to workstations.

DHCP works like this: When a DHCP client starts up it initiates a brief dialogue with a DHCP server on the network. The server responds by sending an IP address it has selected from a list or pool of available addresses, along with other configuration data including a lease time that tells the client computer how long it may use the assigned IP address. The client is programmed to ask for a renewal of the lease periodically, which the server will normally grant. If the server doesn't hear from the client before the lease time expires, it assumes that the client is no longer connected. That client's IP address then goes back into the pool for re-assignment. This capability enables more efficient use of scarce IP addresses.

Dynamic DNS (DDNS)

DHCP is "dynamic" because a DHCP server can assign available IP addresses to clients automatically in response to their requests. 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) is merely 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. This is best accomplished if the DNS and DHCP servers are integrated within a common, distributed directory service.

Novell Directory Services (NDS)

A directory service is a database of objects representing the users, applications, network devices and other resources you might find on a network. Within each object is stored specific information about the individual user or resource. Objects are structured hierarchically in a directory tree that can be organized the way your business is organized.

A directory service manages relationships between the elements of a network. Every user or resource has some relationship with other users and resources on the network. A directory controls the relationships between people and machines and between one machine and another. A directory manages relationships through authentication and authorization.

A directory service authenticates both the user and the network components. They need to identify themselves to each other to ensure both are who they say they are and prevent anyone from getting in between to steal information.

A directory service authorizes users to use different parts of the network. Once a user is authenticated, the network authorizes the user to manage or use network resources to which the user has rights. Rights are distributed globally, organizationally or across workgroups and then managed by exception at the individual user levels.

NDS is the only directory service that addresses all aspects of a network, enabling single sign-on, single point of management and a foundation for developers to build upon. NDS spans all network components, including physical devices such as modem banks, access servers, and routers; operating systems such as NetWare, UNIX, and NT; applications that run over the network; and services that improve how people work with the network, the intranet and the Internet.

Advantages of Novell DNS/DHCP Services

The following table summarizes key features of Novell DNS/DHCP Services:

Benefits of Novell DNS/DHCP Services


Benefit
Explanation

Simplifies IP name and address management through NDS

Extends the NDS database schema to include DNS host names and DHCP- administered IP addresses, giving you access to all your network information in a replicated, distributed database.

Reduces management costs

Reduces the cost of administering IP addresses by as much as 83 percent, according to research conducted by Gartner Group, Inc.

Ensures high fault tolerance

Because the NDS database is replicated, the DNS and DHCP data is available in multiple locations across the network, creating virtual DNS and DHCP servers within NDS.

Creates secure environment for DNS and DHCP data

NDS's industry-leading security and authentication features protect all your DNS and DHCP information. NDS enables you to define rights quickly and reliably for any branch of the directory tree. Rules-based security and inherited rights greatly reduce administrative costs and prevent data loss.

Eliminates the need for zone transfers

When you update DNS data in any NDS server, it is replicated across the network and is immediately available to any NDS-based DNS server.

Acts as primary or secondary server with traditional Berkeley Internet Name Domain (BIND) DNS servers

Novell's DNS also supports the traditional primary/secondary approach to move DNS data in and out of NDS. The Novell DNS server can act as either a master or secondary DNS server in relation to non-Novell DNS servers and transfer data into NDS. All Novell DNS Servers can then access the data through NDS replication.

Automates IP address assignment and host name updates

When a host is assigned an IP address by DHCP, the update is recorded in NDS. The DNS information can then be automatically updated to associate the host name with the new address. You can also use Dynamic DNS (DDNS) to update DNS with information about addresses assigned and rescinded.

Provides custom IP address assignment and configuration capability at global, subnet, or user level with NDS inherited rights

You can assign lease times, static IP address and configuration to a client with a specific MAC address. You can also create and maintain a hardware exclusion list through which you can deny DHCP service to certain devices by their MAC addresses.

Includes the easy-to-use, policy-based Java Management Console

DNS/DHCP comes with the new policy-based Java Management Console that has a task-oriented interface for configuring and managing the NDS objects related to DNS and DHCP. It can be run as a standalone utility at a client workstation, or it can be accessed from the Tools menu of the NetWare Administrator utility.

Supports industry standards

The DNS software in Novell DNS/DHCP is based on BIND 4. 9. 6. The DHCP software conforms to RFCs 2131 and 2132.

Imports and exports DNS and DHCP data

With DNS/DHCP, DNS data can be read in from a BIND master file to populate NDS. DNS data can also be exported out of NDS into BIND master file format. This aids in upgrading from or interoperating with BIND 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 other compatible DHCP formats.

Increases flexibility and scalability of your network

A Novell DNS server can be authoritative for multiple domains. In addition to being authoritative for zones, a Novell DNS server can act as a caching or forwarding server. The DNS/DHCP software supports multihoming and round-robining of responses to queries with multiple records for a domain.

Challenges of IP Management

The current IP specification (IPv4) provides 32-bits of address space, which translates to just over 4 billion possible addresses. But only a small percentage are actually available for use, partly because of the tremendous growth of Internet use worldwide, and partly because of inefficient assignment of addresses in the early years. From the pool of remaining numbers, 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 (to 128 bits), the limitations of IPv4 will be with us for some time.

Traditionally, keeping network devices accurately configured meant you had to do two very tedious and time-consuming things. One, you had to personally visit each workstation on the network to configure it with the data. Two, you had to maintain an accurate list of available IP addresses to assign to the various devices.

Common methods for keeping track of IP addresses involved paper lists or spreadsheets that had to be manually updated when you added, deleted, or moved a network device. For all but the smallest networks, this could become a real nightmare, with a high probability for mistakes. Accidentally assigning duplicate addresses to two computers could freeze up part of your network.

Although DHCP helps automate the configuration process, traditional DHCP implementation still requires a lot of administrative effort to keep everything in sync. And some types of devices need permanent, or static, IP addresses, which must be assigned manually anyway.

And another problem when a DHCP server assigns a new address, or you assign one manually, how does that information get to DNS? DNS and DHCP were not really designed to work with each other. What you really need is some way to combine the two technologies. You need some kind of integration a way to quickly and conveniently distribute DNS and DHCP capabilities throughout your network.

In the past, DNS has been administered by building a database of information including all of a zone's resource records. Like managing IP addresses, managing these files is also difficult and time-consuming. 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 updates are made to the primary name server, the entire contents of the database file must be copied to any secondary name servers.

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 management points, which constrains the physical location of these servers and often requires considerable TCP/IP expertise to maintain the system.

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 typically provided in the form of secondary DNS servers. However, the primary DNS server still represents a single point of failure.

Since organizations have a wide range of client and server systems, it is important for new solutions to support a heterogeneous environment. In particular, many sites have client workstations that are still using DHCP's predecessor, BOOTP. These sites need 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 from the old systems to the new. This makes migrating to the new system easier, and allows you to do it at your own pace.

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. Version 4. 9. 6 of BIND is the one most commonly used today.

Putting DNS Into NDS

By integrating DNS services 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 a zone, the data is available to any of the Novell DNS servers that are authoritative for that 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 failure inherent in traditional server-centric solutions.

To interoperate with other DNS servers, Novell's DNS can move DNS data in and out of NDS using the traditional primary/secondary approach. The Novell DNS server can act as either a primary or secondary DNS server in relation to non-Novell DNS servers. A Novell DNS server acting as the primary DNS server transfers data out to non-Novell secondary servers. A Novell DNS server acting as a secondary DNS server transfers data in from a non-Novell primary server. All Novell DNS Servers can then access the data through NDS replication.

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 network administrator assigns this server to perform certain one-time tasks, which vary depending on whether the server is acting as a primary or a secondary server for the zone.

If the server is acting as a primary server it's called the dynamic DNS server. One of the dynamic DNS 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).

If it's acting as a secondary server for the zone, it's called the zone-in server. The zone-in server is responsible for requesting a zone transfer of data from the external primary name server. This server determines what data has changed for a zone and then makes updates to NDS so that other servers are aware of the changes.

If you are running a primary name server and providing DNS service for that domain, the size or geography of your network might suggest creating zones within that domain. Keep the zone data as a separate partition, and replicate the partition to all places on your network where you have a name server for the zone. This enables independent replication of the zone data and also provides a degree of fault tolerance in the case of server downtime.

You must install the Novell DNS server as a primary name server to have authoritative control over your zone and to take advantage of the dynamic updating of NDS. When operating the Novell DNS server as a primary name server, you use the Management Console to make configuration changes. When you operate a primary name server, the zone data receives dynamic updates from DHCP servers. Non-Novell secondary name servers can transfer data into the Novell primary name server.

If you plan to operate a server using Novell DNS as a secondary name server to a non-Novell master name server, use one Novell name server, the designated server, to transfer data from the non-Novell primary name server. The Novell server receives information from the non-Novell primary server and provides updates to NDS. Other Novell secondary name servers can access the information within NDS.

Some of the reasons for operating a Novell secondary name server to a non-Novell master name server include the following:

  • You have been using a Master DNS server and don't want to become a primary because of the responsibility it entails.

  • It is easy to implement in your existing DNS model.

  • You want to install more secondary name servers to provide better load balancing.

  • You want to gradually make the move to operating a primary name server.

If a name server cannot answer a query, it must query a remote server. You can configure primary or secondary name servers to act as forwarders. When you designate a server to be a forwarder, all off-site queries are first sent to the forwarder. Forwarders that handle the off-site queries develop a robust cache of information. There is a very good chance that the forwarder can answer any given query with information from its cache, eliminating the need to make an outside query to a remote server.

When you decide to make a server a forwarder, configure the other servers in your zone to direct their queries through the forwarders. When a forwarder receives a query, it checks its cache for the information. If it is unavailable, the forwarder issues a query to the remote server.

The IN-ADDR.ARPA zone provides inverse addressing: the ability to find host names when the IP address is known. In the structure of the IN-ADDR.ARPA zone, the IP address appears in reverse order. In other words, if a host has an IP address of 1. 2. 3. 4, the address in the IN-ADDR.ARPA subdomain would be 4. 3. 2. 1. in-addr. arpa. Inverse address zones use PTR resource records to provide mapping from addresses to domain names.

Putting DHCP Into NDS

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 same lease time for all DHCP clients. Additional DHCP and vendor options that can be assigned along with lease time include the following:

  • Domain name

  • NetWare/IP settings

  • Service Location Protocol (SLP) options

  • NetBIOS name server

  • NIS/NIS+ domains/servers

  • Subnet masks

  • User-defined option tags

  • NDS options for NetWare 5

You can create and maintain a hardware exclusion list through which you can deny DHCP service to certain devices by their MAC addresses.

When planning your implementation of DHCP, consider the following issues:

  • Your existing network topology how you set up your routers and subnets provides a basic configuration for the distribution of DHCP resources such as Subnet objects, Subnet Address Range objects, and IP Address objects.

  • Incorporate your existing NDS implementation into your planning. Place the Locator object near the top of your NDS tree where it can be easily accessed by all servers.

  • The length of time you set for your leases affects traffic on the network.

Example Lease Times


Lease Time
Rationale

15 minutes

Keeps the maximum number of addresses free when there are more users than addresses available, but results in significant traffic

6 hours

Covers a DHCP server outage of 6 hours

12 hours

Ensures that retraction of address assignment takes less than one day

3 days

Used by many sites simply due to software defaults

6 days

Affords a weekend server outage without losing leases

4 months

Enables students to keep their address over a summer vacation, for example

There is usually a trade-off when attempting to control specific client access to leases. Normally, you would have to manually configure each client and dedicate an IP address permanently to each client. Novell's DHCP server, however, provides granular control to a pool of leases based on the client's MAC address.

Novell has created the next generation of DNS/DHCP services by extending the NDS schema with new DNS/DHCP objects and relationships, adding impressive new capabilities to the industry's premier directory service. After all, one of the most powerful features of NDS is its extendability. And with the new DNS/DHCP Services, Novell has capitalized on that extendability to make DNS/DHCP services easier, more convenient, and more secure than ever before. The following table summarizes the new NDS objects that make it all possible:

New NDS Objects in DNS/DHCP Services


Object
Description

DNS/DHCP Group

A standard NDS group object that is 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 Objects


Object
Description

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 ResourceRecord Set (RRset)

An NDS leaf object located within a DNS Zone object. It represents an individual domain name within the zone.

DNS Server

A leaf object that stores DNS server configuration parameters.

DHCP Objects


Object
Description

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. The object is created by the administrator for static address assignment or by the DHCP server to represent a dynamic address assignment.

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.

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.

Understanding the NDS Schema Extension

As part of the Novell DNS/DHCP Services software installation process, the NDS schema is extended. The NDS schema extension defines the additional NDS objects needed for DNS and DHCP.

Two global NDS objects are created when the schema is extended: the DNS/DHCP Group object and the DNS/DHCP Locator object. Only one Group object and one Locator object exist in an NDS tree. The DNS servers, DHCP servers, and the DNS/DHCP Management Console must have access to these objects.

The DNS/DHCP Group object is a standard NDS group object. The DNS and DHCP servers gain the rights to other data within the tree through the Group object. When the DNS/DHCP Management Console is used to create DNS and DHCP servers, the servers have the rights to access data.

The DNS/DHCP Locator object contains global defaults, DHCP options, and lists of all DHCP and DNS servers, subnets, and zones in the tree. The DNS/DHCP Management Console can display these objects without having to search the tree. The Locator object is not visible within the DNS/DHCP Management Console interface.

The DNS/DHCP schema extension adds the following new NDS objects to support DNS:

  • DNS Zone object

  • DNS Resource Record Set object

  • DNS Name Server object

The DNS Zone object is a container object that holds all the data for a single DNS zone. A Zone object is the first level of the DNS zone description. Multiple DNS zones can be represented within NDS by using separate, independent DNS Zone objects. A network administrator can support multiple DNS zones on a single NetWare server by creating multiple DNS Zone objects and assigning the server to serve those zones. The zone object can be contained by an Organization (O), Organizational Unit (OU), a Country (C), or a Locality (L).

The DNS resource record set (RRSet) object is an NDS leaf object contained within a DNS Zone object. An RRSet object represents an individual domain name within a DNS zone. Its required attributes are a DNS domain name, an address class, and a Time-to-Live (TTL) record.

Each domain name within a DNS zone object has an RRSet object. Each RRSet object contains additional information about the domain, and includes one or more resource records (RRs), and a description of the object and version information.

The DNS Server object is a separate entity from the NetWare Core Protocol (NCP) Server object. The DNS Server object contains DNS server configuration parameters, including the following:

  • Zone List

  • DNS Server IP Address

  • DNS Server Options

  • Forwarding List

  • No Forwarding List

The following new NDS objects support DHCP:

  • Subnet object

  • Address Range object

  • IP Address object

  • DHCP Server object

  • Subnet Pool object

The Subnet object represents a subnet and is the most fundamental DHCP object. The Subnet object can be contained by an Organization, (O), Organizational Unit (OU), a Country (C), or a Locality (L). The Subnet object acts as a container object for the IP Address and Address Range objects. A Subnet object's specific DHCP options and configuration parameters apply to the entire subnet and override global options.

The Address Range object is used primarily to create a pool of addresses for dynamic address assignment or to identify a range of addresses to be excluded from address assignment. Optionally, the Address Range object also stores the start of a host name that can be assigned to clients when addresses are assigned.

You can use multiple address range objects under a subnet object. You can also specify different range types, such as a range for dynamic address assignment, a range for BOOTP clients, or a range to be excluded from the subnet.

The IP Address object represents a single IP address. The IP Address object includes an address number and an assignment type. The assignment type is "dynamic" for address objects created by the server to represent addresses assigned dynamically from an address range.

You must use the DNS/DHCP Management Console to configure IP Address objects that are manually assigned or excluded from assignment. For dynamically or automatically assigned client addresses, DHCP creates an IP Address object under the subnet where the address is assigned. An IP address can be assigned to a client based on the client's MAC address. These IP Address objects can also receive specific DHCP or BOOTP options. Address objects contain the lease expiration time for both dynamically and statically assigned addresses.

When configuring an individual IP Address object, you can provide specific options that override global options or those set at the subnet level. When you create or modify an IP Address object manually, you can also create the necessary DNS RRs.

The DHCP Server Object represents the DHCP server and contains a multivalued attribute listing of the subnet ranges this DHCP server is servicing. The DHCP server also contains all server- specific configuration and policy information.

The Subnet Pool object provides support for multiple subnets through a DHCP or BOOTP forwarder by identifying a pool of subnets.

DHCP servers are not required to be on the local subnet to which they assign addresses. If desired, they can be deployed centrally and service remote subnets. Initial DHCP/BOOTP DISCOVER requests, however, will not be sent to a DHCP server unless a DHCP/BOOTP forwarder local to the client has been configured to forward the addresses.

The Subnet Pool object contains a list of subnet object references (a list of subnet objects of the same type within the pool) and comments.

NDS Considerations

As stated above, when the DNS and DHCP servers are installed and configured, they extend the NDS schema to create new objects with which to administer and control their services. The Group and Locator objects are central to Novell's implementation of DNS and DHCP.

Novell recommends that you place the Group and Locator objects within a container that can be accessed from and replicated to all points of the network that use DNS or DHCP services. Although changes to the Group and Locator objects occur infrequently (only when you add or delete new servers, zones, or subnets), DNS and DHCP servers and the DNS/DHCP Management Console need access to copies of these objects.

In order to maintain optimal performance when providing DNS and DHCP services on your network, you'll need to consider the following important NDS issues:

  • Where to locate the Group and Locator objects

  • Where to locate DNS and DHCP servers

  • What replication strategy to employ

  • How to provide fault tolerance

Create either an Organization (O) or Organizational Unit (OU) container object near the top of your NDS tree. The location of this container should be easily and widely accessible. Locate the Global and Locator objects under the container object.

Locate your DNS and DHCP servers physically close to the hosts that require their services, with one DHCP server in each partition of your network to minimize any WAN communications problems caused by normal load, configuration changes, or replication.

Well-planned replication is the best way to provide fault tolerance for DNS and DHCP services. When planning your DNS replication strategy, consider that replication is employed for load balancing when you provide secondary name servers within the DNS zone. Replicate the partition containing the Group and Locator objects to all parts of the network that use DNS and DHCP services to ensure access in the event of system unavailability or hardware problems. Replicate each DHCP server's database with servers that share high data-transfer rates.

Compatibility with BOOTP

DHCP is based on the Bootstrap Protocol (BOOTP) and maintains some backward compatibility. BOOTP was designed for manually configuring the host information in a server database. Novell has extended support for BOOTP to provide Dynamic BOOTP support. A pool of addresses can be set up for BOOTP address assignment so each BOOTP address does not have to be configured separately.

From the client's point of view, DHCP is an extension of BOOTP, enabling existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software.

There are two primary differences between DHCP and BOOTP. (1) With DHCP, clients receive IP addresses for a specified period of time. With BOOTP there is no lease time; address assignments (even in Dynamic BOOTP) are permanent. (2) DHCP also provides a way to configure a client's other IP options. BOOTP provides only IP addresses.

Another difference between the two protocols is a change in terminology to clarify the meaning of the vendor extension field in BOOTP messages. With DHCP, this field is called the option field.

If multiple servers service a single subnet, only one server, the principal server, can be designated as an automatic BOOTP server.

Dynamic DNS

The Dynamic DNS (DDNS) feature of DNS/DHCP Services software provides a way to update DNS with accurate A and PTR RRs for address assignments made by a DHCP server. These RRs are needed so that both name to address and address to name DNS resolutions can be made. DDNS eliminates the need for further error-prone configuration of DNS for each host address change.

DDNS is enabled by configuring a Subnet Address Range with Always Update turned on. You must also specify a zone reference in the Subnet object so the DHCP server knows which zone to update.

When DDNS is active, the DHCP server updates the designated primary server for the zone that adds or deletes the corresponding A and PTR RRs. The DHCP server also notifies the designated primary server when leases expire, causing the A and PTR RRs to be deleted.

Only Subnet Address Ranges that are configured as Dynamic DHCP or Dynamic DHCP and Dynamic BOOTP can use the Dynamic DNS update feature. For DDNS update to occur, Always Update must be turned on in the range's DNS update option and a DNS zone must be specified to link the zone object to the subnet. When these conditions are met, the DHCP server initiates a Dynamic DNS update when an address is assigned to a client.

When a client that is subject to DDNS updates is granted a lease by the DHCP server, the server updates its own database and NDS to store the transaction. The DHCP server also contacts the DNS server and submits a request for DNS update. The DNS server maintains resource records for each client. It maps domain names to IP addresses using A records, and maps IP addresses to domain names using PTR records. When DDNS is enabled and a client receives an address from the DHCP server, the DNS server updates both of these records. Likewise, when a client subject to DDNS updates loses or ends its lease, the DNS server receives the DDNS update request and deletes the PTR and A records associated with that client.

Managing DNS/DHCP Services

This section provides information about the DNS/DHCP Management Console, the policy-based Java application that is used to configure and manage DNS and DHCP within NDS. The DNS/DHCP Management Console is an independent, executable Java application designed to run on a Windows NT workstation with Novell Client 32 loaded. The Management Console can also be launched from NetWare Administrator. Future plans call for the utility to be platform- independent, able to run on Windows 95 and non-PC platforms such as UNIX and Macintosh.

When the DNS/DHCP software is installed, the Locator object is created in NDS. Since the Locator object serves as the catalog for most of the DNS/DHCP objects, the DNS/DHCP Management Console is not required to search or scan the entire NDS tree to collect objects for initial tree display. Read/Write rights to the Locator object should be granted to network administrators so they can use the Management Console to create, update, or delete DNS/DHCP objects as necessary.

The DNS and DHCP Service Tabs

There are two main tabs within the DNS/DHCP Management Console: DNS Service and DHCP Service. Each tab contains three panes. The left pane displays the managed objects in tree form. The right pane displays the detailed information about the highlighted object in the left or bottom pane. The icons in the bottom pane identify the DNS or DHCP servers that have been configured. The figure below shows the main user interface window for the DHCP Service.

Figure 1: DHCP Service user interface

The resources are organized according to the object hierarchy and the implicit ordering of objects. For example, all IP addresses displayed within the left pane of the DHCP Service tab are in ascending numeric order. In the DNS Service pane, all zones or resource records within zones are listed in alphanumeric order.

By double-clicking a logical container object in the left pane, such as a Subnet or a Subnet Address Range, you can expand the object to view subordinate objects or collapse it to see a concise view of the entire database.

When you click the Create button in the tool bar, a dialog box appears that enables you to choose the type of object you want to create, as shown in the following figure:

Figure 2: The Create dialog box

All DNS and DHCP objects are created as NDS objects and are subject to NetWare Administrator convention. Therefore, when creating a new object, you should always name the object first in each Create dialog box. Some objects, such as DHCP server, DNS server, DNS zone, Subnet, and Subnet Pool, can be created in any context. The Create dialog box of these objects has a browse button, enabling you to choose any context for which you have Write or Supervisor rights.

After a new DHCP or DNS object has been created, the DNS/DHCP Management Console grants the object Read/Write rights to the Locator object.

SNMP Event Generation

You can use the DNS/DHCP Management console to set up SNMP event generation in the case of NO_TRAP, MAJOR_EVENTS, and ALL. The default setting is MAJOR_EVENTSand obligates the server to log all major and critical events.

Critical events are those that cannot or should not be ignored by the network administrator. Major events denote a significant change in the state of the server processing. Warning and Minor events are logged for maintenance and diagnosis only. Warning and Minor events should not be turned on unless a problem has developed.

All critical and some major events are logged on the local server console.

The following warning events can be logged or trapped for SNMP event generation:

  • An NDS update to the subnet failed, causing degraded operation (logged to local file).

  • An internal fault recovered and the error code was logged.

  • A subnet was not configured and addresses are not available, causing degraded operation.

The following minor events are logged and/or trapped for SNMP event generation:

  • A "Decline" was generated against an IP address.

  • All logged file transactions have been reprocessed (operational.)

The following major events are logged and/or trapped for SNMP event generation:

  • The DHCPSRVR NLM is loaded; the server is operational and ready for LAN-based clients.

The following critical events are logged and/or trapped for SNMP event generation:

  • The logger cannot open the recovery log file or is having difficulty opening it. (The server is inoperative.)

  • The main thread cannot process lease expiration. (The server is inoperative.)

DHCP Auditing

Auditing can be used to perform an analysis of historical data and to help diagnose operational difficulties. Auditing uses CSAUDIT and the Btrieve database to store and manage data enabling meaningful trend analysis. The stored database information can be accessed by a remote analysis program.

When auditing is enabled, every incidence of address deletion, addition, and rejection is recorded in the audit log. The beginning and end of each session is marked to help make sense of the audit log. The beginning session contains records defining the session in terms of addresses already assigned.

Additionally, other major events or alert situations that cause SNMP traps are also audited. Other incoming DHCP requests are also logged, including honored renewal requests and those rejected or dropped.

Conclusion

By integrating DNS and DHCP technology into NDS, Novell DNS/DHCP Services software brings the convenience, power, and security of the industry's premier directory service to IP network management. This highly compatible, standards-based DNS/DHCP solution at once streamlines and simplifies the configuration, administration, and maintenance of your intranet, providing significant time and cost savings throughout your enterprise, and greater safety for your sensitive data.

You can order DNS/DHCP Services from any Novell Authorized, Gold, or Platinum Partner. For more information, contact your local Novell office or call the Novell Customer Response Center at 1-801-228-4CRC (1-801-228-4272). In the United States and Canada, you may call toll free 1-888-321-4CRC (1-888-321-4272). You may also visit Novell's World Wide Web site at http://www. novell.com.

Appendix A: Supported Standards

DNS


RFC Number
Description

RFC819

Domain Naming Convention for Internet User Applications

RFC920

Domain Requirements

RFC974

Mail Routing and Domain System

RFC1032

Domain Administrators Guild

RFC1033

Domain Administrators Operations Guide

RFC1034

Domain Names Concepts and Facilities

RFC1035

Domain Names Implementation and Specification

RFC1101

DNS Encoding of Network Names and Other Types

RFC1122

Requirements for Internet Hosts Communication Layers

RFC1123

Requirements for Internet Hosts Application and Support

RFC1183

New DNS RR Definitions

RFC1535

A Security Problem and proposed Correction with Widely Deployed DNS Software

RFC1536

Common DNS Implementation Errors and Suggested Fixes

RFC1537

Common DNS Data File Configuration Error

RFC1591

Domain Name System Structure and Delegation

RFC1597

Address Allocation for Private Internets

RFC1627

Network 10 Considered Harmful (Some Practices Shouldn't Be Codified)

RFC1713

Tools for DNS Debugging

RFC1884

IP Version 6 Addressing Architecture

RFC1886

DNS Extensions to Support IP Version 6

RFC1912

Common DNS Operations and Configurations Errors

RFC2010

Operational Criteria for Root Name Servers

RFC2052

A DNS RR for Specifying the Location of Services (DNS SRV)

DHCP


RFC Number
Description

RFC1035

Domain Names Implementation and Specification

RFC1036

Standard for Interchange of USENET Messages

RFC1183

New DNS RR Definitions

RFC2131

Dynamic Host Configuration Protocol

RFC2132

DHCP Options and BOOTP Vendor Extensions

RFC2241

DHCP Options for Novell Directory Services

RFC2242

NetWare/IP Domain Name and Information

BOOTP


RFC Number
Description

RFC1497

BOOTP Vendor Information Extensions

RFC1534

Interoperation Between DHCP and BOOTP

RFC1542

Clarifications and Extensions for the Bootstrap Protocol

Appendix B: Registering Your DNS Server with the Root Servers

If you plan to operate a primary DNS name server, you must register your name server with your parent domain. Not all your name servers need to be registered, but it is a good idea to register one-third to one-half of your name servers (up to a maximum of ten) with the parent domain. These are the servers that are queried by servers from outside your domain. The remaining name servers are only queried by hosts within your domain configured to query them. If you provide an authoritative name server for other domains, you must also register those domains.

To register a domain (and subdomain), you must contact the administrators of the parent domain (.com, for example) and the in-addr.arpa domain. Provide them with the name of the domain name server and the name of the domain and any subdomains for which it is authoritative. If you are setting up a new domain, you also need to provide the IP address of any server you want to register.

InterNIC is the organization that registers domain names for the root, .com, .org, .net, .edu, and .gov domains. To obtain the form for domain registration from InterNIC, contact them at http://rs.internic.net. You can also obtain the form for in-addr.arpa domain registration from the same location. Detailed information about the registration process is available from the InterNIC Web site. You can also use the InterNIC Web site to research domain names to ensure that the name you want is not already registered and to get additional information and help.

The following list outlines the registration process:

  1. Prepare to register your domain.

  2. Fill out the Domain Name Registration Agreement and E-mail it to hostmaster at InterNIC.

  3. Your request is automatically processed, assigned a tracking number, and checked for errors.

  4. The agreement is processed, and you are notified when the process has been completed.

  5. Information about the new domain is added to InterNIC's WHOIS database and transferred to zone files.

  6. InterNIC sends an invoice to your designated billing contact for the registration fee.

  7. You pay for your domain name registration, which is good for two years.

Appendix C: System Requirements

Hardware Requirements

The server has the following hardware requirements:

  • Pentium-based PC or above

  • 64 MB RAM

  • 15 MB free disk space

  • CD-ROM drive

The Java Management Console has the following hardware requirements:

  • Pentium/166-based PC

  • 64 MB RAM

  • 10 MB free disk space

  • Super VGA monitor with a minimum resolution of 800 x 600 pixels and 256 colors or above

Software Requirements

The server has the following software requirement:

  • NetWare 5 (NetWare 5 will include DNS/DHCP Services.)

The Java Management Console has the following software requirements:

  • Windows NT 4.0 with Windows NT 4.0 Service Pack 3

  • intraNetWare Client for Windows NT

The workstation has the following software requirement:

  • Any client that conforms to BOOTP or DHCP standards, including Windows NT, Windows 95, UNIX, OS/2, or Macintosh.

Appendix D: Glossary

Authoritative. DNS data that is served by the resident DNS server, either primary or secondary. Authoritative DNS data belongs to a resident domain and is managed by the administrator of that domain, or it is DNS data that is imported through a zone transfer.

BOOTP. The Bootstrap Protocol preceded DHCP and was designed for manual configuration of the host information in a server database.

DNS. The Domain Name System is a distributed database system that provides name-to-IP address mapping for computers on an internetwork or the Internet.

Domain. A label of the DNS tree; each node on the DNS tree represents a domain. A domain is also known as a zone.

Domain Name Space. An inverted tree structure, the DNS hierarchy is much like the structure of NDS.

Domain Name Service. The component of DNS that provides the actual name-to-IP address mapping to locate another computer on the internetwork or Internet.

Dynamic DNS Server. The one Novell server for a primary zone that is responsible for making changes to the zone as a result of Dynamic DNS. The zone itself is not mastered by the designated server but stored within NDS.

Name server. A server that maintains a database of information about hosts in a specific zone. Each DNS zone must include a name server containing information about each host in the zone.

NDS. Novell Directory Services.

NDS Schema. The rules that govern the operation of NDS.

Root Domain. The domain (or node) at the top of the DNS tree.

RR. A DNS resource record.

Rrset. The collection of resource records that are composed of the same name, type, and class.

SOA. Start of authority.

Zone Transfer. The mechanism used by DNS servers to update each other by transferring Resource Record images.

Zone-in DNS Server. The Novell server for a secondary zone that is responsible for requesting a zone transfer from the external primary server. The designated secondary server updates the zone data in NDS as it receives zone transfers, so all Novell servers for a zone can respond to queries against the zone.

* 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