Novell is now a part of Micro Focus

Novell DNS/DHCP Services: Design Issues and Troubleshooting

Articles and Tips: article

AMITABH SINHA
Product Planning Manager
Novell, Inc.

01 Nov 1998


Provides a brief introduction to Novell DNS/DHCP Services and discusses design and troubleshooting issues that you may encounter in implementing an IP-only environment for your NetWare 5 servers.

Overview

NetWare 5 is a Pure IP-based network operating system. Although it accommodates IPX users, making it backward compatible with intraNetWare (NetWare 4.11), most organizations today prefer running only one protocol over the cable. With the proliferation of the Internet into businesses and homes worldwide, Internet Protocol (IP) is the most widely used communication protocol. It makes sense then to take advantage of the convenience and speed of a Pure IP environment like NetWare 5 for IP-based applications and software.

Using IP as a network's native protocol implies that every client needs an IP address in order to talk to the server. It is a very cumbersome task for a system administrator to physically go to each workstation and configure their IP addresses. To simplify the management of IP addresses, Novell adds value to NetWare 5 by including its Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) Services, which integrate tightly with Novell Directory Services (NDS).

This AppNote provides a brief introduction to Novell DNS/DHCP Services and discusses design and troubleshooting issues that you may encounter in implementing an IP-only environment for your NetWare 5 servers.

Introduction

Novell DNS/DHCP Services is standards-based software that integrates DNS and DHCP into 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. Below are brief explanations of these services.

Domain Name System (DNS)

DNS is basically 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.

The name service component of DNS 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 sub-domains 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.

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 DHCP servers that automatically hand out addresses and other parameters to workstations.

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, as its name suggests, is "dynamic" because a DHCP server can assign available IP addresses to clients automatically in response to their requests. That means a particular client with 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 Resource Records 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.

Differences between DHCP 2.x and DHCP 3.x

Novell has provided DHCP services, beginning with intraNetWare. This DHCP 2.x service was based on a text file database and provided automatic IP addressing for small- to medium-sized organizations. As networks grew and more and more IP addresses were needed from intraNetWare servers, the servers' performance degraded and problems like corruption in DHCPTAB file or duplicate IP addresses were frequent. Managing this version of DHCP was also very cumbersome as its management utility used the C-worthy interface and was server centric.

To overcome these problems, Novell introduced NDS-enabled DHCP 3.x with NetWare 5. This version uses NDS as the database to store all the DHCP- based objects. In intraNetWare, two separate NLMs were needed for both local (DHCPSRVR) and dial-up (DHCPD) clients. In NetWare 5, DHCPSRVR issues IP addresses to both local and remote dial-up clients.

One key feature of DHCP 3.x is the "Ping Ahead" option for the server. Enabling this option eliminates the possibility of having duplicate addresses on a subnet. If this option is enabled, the DHCP Server will ping each IP address before allocating it to the client. It can be easily configured from the graphical management console by enabling or disabling the PING depending upon your requirements, as illustrated in Figure"1.

Figure 1: Check the "Ping Enabled" option if you want to use this feature.

NDS Objects for DHCP

When you install Novell DNS/DHCP Services, a schema is extended to you automatically. This is done to create new NDS objects to facilitate DNS and DHCP objects. NDS-enabled DHCP creates the following objects in the NDS tree:

DHCP Server Object. The DHCP Server object represents the DHCP server and contains a multi-valued attribute listing of the subnet ranges the DHCP server is servicing. The DHCP server also contains all server-specific configuration and policy information. A DHCP Server object can be contained in an Organization (O), an Organizational Unit (OU), a Country (C), or a Locality (L) container.

Subnet Object. The Subnet object represents a subnet and is the most fundamental DHCP object. The Subnet object can be contained in an O, OU, C, or L. The Subnet object acts as a container object for the IP Address and Address Range objects.

Subnet Pool Object. The Subnet Pool object provides support for multiple subnets through a DHCP or BOOTP forwarder by identifying a pool of subnets for remote LAN address assignments. A Subnet Pool object can be contained in an O, OU, C, or L.

Address Range Object. The Address Range object is primarily used to denote a range of addresses 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 stores the start of a hostname that can be assigned to clients when addresses are assigned.

IP Address Object. The IP Address object represents a single IP address. The IP Address object must include an address number and an assignment type. The address can be assigned manually, automatically, or dynamically, or it can be excluded from DHCP address assignment.

Figure 2 shows an example of how these DHCP objects appear in NDS.

Figure 2: Diagram of NDS objects created by NDS-enabled DHCP.

Storing all the DHCP objects in NDS provides scalability and redundancy: if a server crashes, the configuration data remains available in the replicated NDS database. DHCP 3.x also provides a Java-based administration utility which runs on the client as well. This utility has a user-friendly graphical interface and provides many configuration options.

Differences between intraNetWare DNS and NetWare 5 DNS

With intraNetWare DNS, all the changes were made on a single primary name server. Once changes were made, a zone transfer would take place. This master-slave approach has several disadvantages. The most obvious one is that all changes must be made at the primary server.

Using the primary and secondary zone concept, the NetWare 5 version of DNS allows you to make changes from anywhere within NDS. This is possible because all of the DNS data is stored in NDS, which is available for update from anywhere within the network. In other words, it is not dependent upon a single server and is replicated just like any other NDS object, providing redundancy to the entire domain.

Novell has an earlier DNS server product bundled with NetWare/IP as well as the NetWare NFS product. This version of DNS server was based on a Btrieve database and had many limitations (it only supported one zone and did not support multi-homing). In a large network, these limitations increased traffic as all primaries were involved in zone transfer.

DNS server in NetWare 5 uses NDS to store all of the DNS-related information. The new DNS objects for Novell DNS services are listed below:

DNS Zone Object. The DNS Zone object is a container object that contains all the data for a single DNS zone. A Zone object is the first level of the DNS zone description. A zone object can be contained under an O, OU, C, or L.

DNS Resource Record Set Object. 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.

DNS Name Server Object. The DNS Server object (or Service object) is different from the NetWare Core Protocol (NCP) Server object in that it identifies a DNS Name Server. A DNS Server object can be contained in an O, OU, C, or L.

Figure 3 shows an example of how the DNS objects might appear in NDS.

Figure 3: Diagram of DNS objects for Novell DNS services.

Group Object. An NDS object is necessary for the DNS and DHCP servers to gain rights to DNS and DHCP data within the tree through the group object. The easiest way to understand the objective of this object is while creating the DNS and DHCP objects in the DNS/DHCP management console. Only one Group object is allowed in a single NDS tree.

Locator Object. This is the most important object for the DNS/DHCP services. It contains global defaults, DHCP options, and lists all DNS and DHCP servers, subnets, and zones in the tree. The DNS/DHCP management console can display these objects without having to search the tree by using the Locator object. The Locator object cannot be displayed by the management console; it can only be seen by NWAdmin. This is also allowed one per tree.

These two objects are automatically created at the time of installation.

DNS/DHCP Design Issues

This section covers many of the design and configuration issues that customers have encountered in working with Novell's DNS/DHCP services.

DNS/DHCP in Mixed Environments

A NetWare 5 server can efficiently work in a mixed NetWare 4-NetWare 5 server environment. If you currently have many intraNetWare servers and want to use the Novell DNS/DHCP Services, you do it by simply adding one NetWare 5 server. (All of your intraNetWare servers must be running DS.NLM version 5.99 or later).

A NetWare 5 DHCP server can issue an IP address to any client which follows the RFC1541 specification. It does not matter whether it is a UNIX, MAC, Windows, or NT client.

Locating DNS and DHCP Objects to Ease NDS Traffic

Since NDS is a distributed database, it must synchronize with other servers to transfer the updates at a regular interval. For manageability and to reduce NDS traffic, it is recommended that you maintain the DNS and DHCP objects in a separate container.

It is highly recommended that the DNS/DHCP Group, DNS/DHCP Locator, and the RootServerInfo objects be placed in a separate partition which is replicated to all points of the network where NetWare 5 DNS/DHCP servers are located. It is imperative that this information be available everywhere across the network since it contains the configuration information (such as DHCP server, zones, and subnets). The management utility requires this information before it will allow you to modify the configuration.

Create either an OU, L, or C container object near the top of your NDS tree. This container object should be easily and widely accessible. Locate the DNS/DHCP Group and Locator objects under the container object. It is recommended that the location of thses objects should not be more than 2 or 3 levels deep.

Create an Administrator Group object under this container also. An Administrator Group should have Read and Write rights to all DNS/DHCP Locator object attributes except the global data and options fields. Members of this group can use the DNS/DHCP Management Console to create and modify DNS and DHCP objects. Again, it should not be more than 2 or 3 levels deep.

Whenever possible, try to place your DNS and DHCP servers at locations where they are geographically close to the hosts that require their services. Plan to have one DHCP server in each partition of your network to minimize any WAN communications problems caused by normal load, configuration changes, or replication.

Replicate the partition containing the DNS/DHCP 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.

When planning your DNS replication strategy, consider that replication is employed for load balancing when you provide multiple name servers within the DNS zone.

Optimizing DNS/DHCP Performance

The minimum hardware requirements recommended for your DNS servers are at least a Pentium 200 MHz processor with 64 MB of RAM. If the network is large (if it contains several thousand IP objects or DNS records), more memory will improve performance.

In a DNS environment, even if you have file servers with lower performance than the above configuration, it is highly recommended that you select a powerful machine as the designated server for balanced performance. The reason is that the designated server is involved in the zone transfers from secondaries and DDNS updates.

While planning for storage management, plan ahead for DNS and DHCP servers. If your network is large and you plan to have many DNS and DHCP objects created, it is recommended that you allow some additional disk space on the SYS volume. (On average, each NDS object consumes 4 KB of disk space.)

Wherever possible, restrict the size of any zone to no more than 5,000 DNS objects. Similarly, for DHCP, allow no more than 2048 objects in one subnet.

The workstation where you run the administration utility should be at least a Pentium 200 or better with at least 64 MB of RAM, 800 x 600 resolution and 256 colors or more. Running the utility in a lesser capacity workstation may result in slower performance.

Providing Redundancy for DHCP Servers

The version of DHCP that ships with NetWare 5 does not have any redundancy built in. This means that if Server X goes down, Server Y does not automatically take over. However, you can achieve a certain level of redundancy through the design. Using the procedure below, downtime can be reduced to 5 or minutes or less.

Each Subnet object is assigned to a DHCP Server object. This allows a DHCP server to be responsible for servicing a particular subnet. Consider the example in Figure 4, where you have two DHCP Servers (X and Y) on the same segment. They are both servicing many subnets. The key advantage here is that all of the configuration information is in NDS and not on the servers, so you don't risk losing all of the subnet information in one of the servers goes down. When using NDS, the data is available on all the servers, so if X goes down, configuration information about the subnet serviced by Server X is still available on Server Y.

Figure 4: NDS provides configuration information about serviced subnets.

To switch over, go to each subnet and change the default DHCP server to Y. Then load DHCPSRVR.NLM on server Y. Server Y will be now responsible for the subnets which were previously serviced by Server X. Since all the configuration information about Subnets, IP addresses, subnet pools, and others are recorded in NDS, every server in the tree has access to the information.

After troubleshooting Server X and fixing the problem, unload DHCPSRVR on server Y. Remove the subnets allocated to Server Y when Server X went down. Finally, load DHCPSRVR again on Server X.

DHCP Deployment over Routers

More and more organizations are growing and spreading all across the world. Once the resources have been deployed, the question asked is: how do we manage them? Novell's DHCP can help ease the IP management burden in wide area networks with remote sites.

Novell's DHCP allows a client from a remote site to request an IP address from a DHCP server via a router. This is achieved by using the Subnet Pool object and configuring the router with BOOTP forwarder to forward any request to a designated DHCP server on the other segment. An example is shown in Figure 5.

Figure 5: Listing of the Subnet Pool from the Management Console.

A Subnet Pool object provides support for multiple subnets through a DHCP or BOOTP forwarder by identifying pools of subnets for remote LAN address assignments. A Subnet object is an NDS object that can be stored in an O, OU, C, or L.

Novell's DHCP server is capable of servicing remote clients. If a DHCP/BOOTP Discover request comes from client A, it will not be forwarded to the remote DHCP server unless the forwarder has been loaded with the forwarder's address.

Another situation may arise where assignment of addresses to multiple subnets being serviced through a DHCP relay agent may be required. This situation may be common in many organizations. The interesting part is that with the advent of virtual LANs and the binding of multiple IP addresses to one interface, problems have come up with clients getting a DHCP address when they are on these secondary subnets. A typical configuration may be as follows.

A router has an interface that is configured with two logical subnets: a primary and a secondary. However, this is one physical segment. There are clients on the primary and secondary subnets and the router is configured to do BOOTP/DHCP forwarding. When the client sends a DHCPREQUEST to the router, it forwards that to the DHCP server with a giaddr being the primary subnet (in this case we need the client to get an address from the secondary subnet). The problem is, how does the DHCP server know that the client is on the secondary subnet when the giaddr in the packet shows the request coming from the primary subnet?

Novell's DHCP 2.x that shipped with intraNetWare could not handle this situation, but DHCP 3.x handles it very well. As mentioned earlier, version 3.x allows you to create a new object called the Subnet Pool object. In one Subnet Pool object you can define multiple subnets. When a DHCPREQUEST comes to the DHCP server through a router with BOOTP/DHCP forwarder loaded, it checks the giaddr to determine if a subnet is configured to service that request.

Configuring DHCPSRVR.NLM for Dial-Up Clients

In NetWare 4.11, there are two different DHCP server NLMs needed in order to service local clients and remote dial-up clients. Using the NIAS (Novell Internet Access Services), it is possible to configure the NetWare server to have dial-up clients getting IP addresses. NIAS 4.1 ships with NetWare 5. DHCP 3.x provides both capabilities (local and dial-up) in a single DHCPSRVR.NLM.

Use the following steps to configure the NetWare server to issue IP addresses to dial-up clients:

  1. Install NIAS 4.1.

  2. Load NIASCFG.

  3. Select Setup.

  4. Select Remote Access Services.

  5. Select PPPRNS = "YES".

  6. From the list of various available protocols, select IP.

  7. In the "Parameters for loading services" box, select "Specify Client address Range = YES".

  8. Specify the Client Start range.

  9. Specify the Client Stop range.

  10. Save the changes and reload the NIAS.

Make sure you are running DHCPSRVR and NIAS on the same server in order to service the dial-up clients.

Importing DHCP and DNS Databases

Novell provides several options for you to migrate to NetWare 5 without losing your existing server configuration. The import utility from the administration console provides a very simple mechanism to convert the old DHCP configuration data from the DHCP.TAB file (IntranetWare or 3.12). This makes Novell's DNS/DHCP services backward compatible with earlier versions of DNS and DHCP services.

NetWare 3.12 and intraNetWare contain the data in Btrieve format. The import utility does not convert the DNS database directly from Btrieve into NDS. First you need to convert the Btrieve database into BIND format before you can import the database using the management utility. To convert the intraNetWare DNS database, follow these steps:

  1. RUN DNSCONVRT.NLM - This looks for the Btrieve file in the sys:etc\dns\hosts.db file and converts it into sys:\etc\dns\h.dat.

  2. Start the administration console and click on "Import the files".

  3. Use the Browse button to point the location of the file to sys:\etc\dns\h.dat.

This converts the BIND format database into NDS format. It will create all the objects for you automatically.

Note: If you have UNIX BIND file, you do not need to perform step 1.

Discovering SLP Services Using DHCP

The IPX compatibility feature in NetWare 5 is a tool that can be used by network administrators to migrate their IPX based networks to IP based networks. The CMD feature provides the connectivity necessary for IPX client/server applications to communicate between nodes that connect to the IP nodes. It also allows IPX client/server applications to communicate between IP nodes and nodes that connect to IPX networks. Connectivity between IPX nodes and IP nodes is achieved through the use of gateways called Migration Agents.

DHCP can be used to help the client workstation find NDS servers, and to help Service Location Protocol User and Service Agents find Directory Agents that are not visible through IP multicast.

In Figure 6, User Agents (UA) and Service Agents (SA) can go to DHCP Server A to learn about DA2. Similarly, UAs and SAs on the other segment can go to DHCP server B to learn about DA1.

Figure 6: UA's and SA's working across the WAN.

Using DHCP options, we can carry one or more CMD configuration parameters. Each configuration parameter is treated as a separate sub-option by the hosts.

The default NetWare 5 client does not send any DHCP packets for parameters. The following two options are very useful in providing the SLP configuration information through DHCP options.

  • Directory Agent (78)

  • Service Scope (79)

Use the following steps to configure your network:

  1. Add a new service (Novell IPX Compatibility Mode) to the network configuration of the Windows NT client.

  2. Reboot the client.

  3. The client sends a DHCPINFORM asking for options 78 and 79.

  4. Configure the DHCP server to respond with these options.

  5. The server will send DHCPACK to the client with options 78 and 79.

In the case where IP Multicast is not available or NDS container replication is not a desirable option, the SLP system can be configured to use DHCP. This is an attractive option for remote office networks where a replicated NDS container might not be a desirable system design.

Compatibility with BIND 8.1.1

The new NDS-enabled DNS is BIND (Berkely Internet Name Domain) 4.9.6 compliant. This was predicated on what the majority of the installed base was operating at. They are clearly at 4.9.x, with 4.9.6 being the latest integration. This DNS can exist in a network with BIND 8.1.1. servers, that is, for zone in/out, forwarding of queries, and so on. This DNS server can also accept a BIND master file from an 8.1.1. version of BIND and import it into our DNS database using the import options.

Following are some of the main features of BIND 8.1.1 and how they impact our DNS implementation:

RFC 1996—NOTIFY. This is a procedure for a DNS Master to notify secondary DNS servers that changes have taken place, and then they can perform zone transfer in order to get the updates. This isn't very important for our DNS server as we use NDS to replicate between the servers (for example, secondary DNS servers —pick-up— zone change themselves directly from NDS rather than from primary DNS servers as these changes are replicated across the NDS partitions.

RFC 2136—Dynamic Update (Without Security). Novell has implemented this in a proprietary fashion. Novell implemented a model where the DNS server receives DNS updates (from our DHCP Server) via a server-to-server IP link. Doing this with other non-Novell servers will be supported in a future release by implementing this RFC as an option (and also possibly enhanced by offering DNSSEC as an option as well).

Other than these two RFCs, BIND releases (8.1.1 to 8.1.2 or 4.9.6 to 4.9.7) generally only add minor fixes. Given the way most vendors of commercial variants of BIND have to cycle these changes into shipping products, it's a given that to stay in lock step with every single change of BIND would be cost prohibitive to us and to most customers.

Zone Transfer between a Novell Secondary and Non-Novell Primary

Since all the DNS data is stored in NDS, you can plan to operate secondary DNS servers using Novell DNS/ DHCP Services software to a non-Novell master name server. One Novell secondary name server must be specified as the Dynamic DNS (DDNS) or "zone in" server. The DDNS server receives zone transfer information from the non-Novell master server and provides updates to NDS. Other Novell secondary or primary name servers can then access the information within NDS (see Figure 7).

Figure 7: Servers communicating zone transfer information using NDS.

Creating a Manual IP Assignment

Manual IP address assignments provides a network supervisor to use DNS/DHCP admin utility to assign addresses to DHCP or BOOTP clients. A particular IP address is assigned to the client based upon its MAC address. These assignments can be permanent or set to expire at a specific time. A typical example would be a backup station that needs a set IP address.

A manual assignment must be an IP address outside of any address range allocated in the range object. For example if you have an address range 130.57.48.0 to 130.57.48.100, you won't be able to create a manual assignment of 130.57.48.87. The manual assignment must be an IP address which does not fall between 130.57.48.0 to 130.57.48.100. In this case you may be able to create a manual assignment using any number between 130.57.48.101 to 130.57.48.125, in other words, 130.57.48.120 can be a valid manual IP assignment.

Troubleshooting DNS/DHCP Services

This section gives some troubleshooting tips for dealing with DNS/DHCP issues.

How to Recover the Locator Object

A DNS/DHCP Locator object repair utility is available from Novell's support web page at http://support.novell.com.This utility provides the following functions:

  • It first scans the entire NDS tree to learn the existence of a DNS/DHCP Locator object and then verifies the object's integrity. If it was accidentally deleted by the administrator, a new one will be created.

  • It then repairs the DNS/DHCP Locator object by comparing its list against all the DNS/DHCP-related objects in the NDS tree. If any discrepancy is found, it adds the missing objects to the DNS/DHCP Locator object. However, it does not delete any objects in the DNS/DHCP locator even if the objects do not exist in the NDS tree.

To run this utility, you need the following four files:

  • FIXLOCATOR.EXE - Program file to launch the utility. Copy the this file into the directory where you install the DNSDHCPAdministrator (for example, novell/dnsdhcp).

  • TOOLS.JAR - Java JAR file to run this utility. It needs to be copied into novell/dnsdhcp/lib.

  • DNIPToolsResources.properties - Resource property file. It needs to be copied into novell/ndsdhcp/lib/nls.

  • The NDDPREFS.DAT file can be copied anywhere on your local machine.

After copying all of these files to their correct locations, you may run FIXLOCATOR.EXE to launch the utility. You need to select the NDS tree from the list before proceeding.

Debugging the DNS and DHCP Servers

Both DNS and DHCP contain command line parameters which can be very useful in getting the information to troubleshoot the DNS and DHCP issues.


Command
Action

LOAD DHCPSRVR - d3

Turns on a background screen log of debug statements and DHCP packets and writes the log to the server's \etc\dhcpsrvr.log file.

For DNS, you can use the following command line parameter to get the debug messages on the server console.


Command
Action

LOAD NAMED - V

Loads the NAMED in verbose mode.

Novell DNS server is based upon Berkeley Internet Name Domain (BIND) 4 series. In some cases where DNS cache will grow and grow overtime until the cache is purged. This is a limitation on BIND 4 series. This memory leak phenomenon is fixed in BIND 8.1.2. Since Novell DNS services still use BIND 4 series, we provide a command line parameter to overcome this limitation and purge the cache.


Command
Action

LOAD NAMED -PC

Used to tell NAMED to purge old cache entries. NAMED can already be loaded and it will handle this situation.

Conclusion

This AppNote touched on the issues which are not covered in the administration guides or in the product manuals. Almost all of the issues are taken from experiences during the NetWare 5 beta-testing where customers were having problems. Summarizing them here gives customers an additional source of technical information so that they can plan and deploy the DHCP and DNS services efficiently in the NetWare 5 environment.

* 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