Cause: The RootSrvr.dat file, which is copied to the sys:\etc\dns directory during the installation, is corrupted or missing. This data file contains information about the DNS root servers and is required to populate the root server's information in the RootSrvrInfo zone object.

Solution: If the installation program cannot find or use this file, it creates the required zone object with default values. The installation process uses the default values for the DNS root servers. The contents of RootSrvrInfo zone object should be compared with the most recent information on the root server. Changes to this information can be made in the RootSrvrInfo zone object by using the DNS/DHCP management utilities.

Cause: The data file NDDPrefs.dat, which is copied to the sys:\system\ directory during the installation, is corrupted or is missing. This data file contains information for global configuration preferences. Currently, only the DHCP global options are configured by using this data file.

Solution: If the installation program is unable to find or use this file, it creates the Locator object with default values for these options. This information can be edited by using the management utilities. In the Management Console, edit this option by selecting DHCP Service > Global Preferences. This page allows you to delete and modify the existing DHCP options and to add new DHCP options.

Cause: While upgrading to NetWare® 6.5, if you have the command load named in the existing autoexec.ncf file, with any option that is not supported by NetWare 6.5, the DNS Server does not load automatically when the autoexec.ncf is executed after upgrading.

Solution: In order to avoid this, before upgrading to NetWare 6.5, ensure that the autoexec.ncf file does not contain the -m, -u, -l, -r, -f, -a, -b, -pc, -strict [on|off], -s, -v, or -q options. For information on DNS server options, see Section 4.7, NAMED Command Line Options.

Cause: The Maximum Memory Cache size is by default set to 0, referring to an unlimited cache size. This indicates that records are purged from the cache only when the TTL for these records expires. The default value for the server to cache the ordinary or positive query cache (max-cache-ttl) is set to 7days and for negative query cache (max-ncache-ttl) it is set to 3 days. So depending on size of the zones being served by DNS Server and the query cache size, memory utilization increases over a period of time.

Solution 1: An increase in memory utilization can be prevented by configuring an adequate size for Maximum Memory Cache size, so that when the amount of data in the cache reaches the specified limit, the records in cache expire and the cache limit is not exceeded. By configuring a smaller value for the memory configuration options such as max-cache-ttl, max-ncache-ttl, and cleaning-interval, memory utilization can be controlled.These memory options can be configured by using iManager or the Java-Based Management Console.

Solution 2: Use command named -pa periodically on system console to purge the contents of the cache. This command cleans the cache and reduces the memory utilization.

Cause: The Start of Authority (SOA) record’s serial number was not properly incremented. Without the serial number increment, the secondary name server does not recognize when a change has been made. This is usually not a problem with DNS based on Novell® eDirectory™ because the serial number is incremented automatically. With UNIX* systems, failure to increment the serial number is the most common cause of DNS errors. The secondary server does not automatically test for changes in the SOA record. Any changes in the SOA record must be accompanied by a change in the SOA record serial number.

Solution: Do not change the SOA record serial number manually with DNS based on eDirectory. If the primary server is not eDirectory based, you might need to change the serial number manually in order for the secondary server to recognize that a change has occurred.

Cause: The receiving DNS server is not a Designated Primary for the reverse/forward zones.

Solution: For dynamic updates from Novell DHCP servers, the targeted forward zone and its corresponding reverse zone should be serviced by the same DNS server in Designated Primary mode. This is to ensure that the DNS server is authoritative for both the forward and the reverse zones.

Cause 1: When you created a new zone, the PTR records were not created or the PTR records have been deleted or changed.

Solution 1: When you configure a zone, always select Yes when prompted to create a companion zone. If you created a companion zone, verify that the IP address and hostname are correct. Checkers can easily catch neglected PTRs. For additional information, refer to RFCs 1537 and 1713.

Cause 2: The host is down or is unreachable.

Solution 2: Use the ping utility to locate the connectivity problem. If the problem exists in your domain, make the necessary repairs to restore connectivity.

Cause 3: The name server for that domain is not configured with information for the host.

Solution 3: Configure the name server for that domain with information for the host.

Cause: The IP address or CNAME alias entry of the host’s primary or secondary name server was changed, but the parent domain was not informed of the change. The address information in the glue record maintained by the parent domain has become invalid. Another possible cause is that the original address information in the glue record for the local zone is invalid or missing.

Solution: When you configure a new zone, always specify the IP address when prompted. Verify that all parent zones have the same address information.

Cause: The IP address of a subdomain’s primary server does not match the hostname and IP address configured in the parent domain for the subdomain’s primary server.

Solution: Verify that the hostname and IP address for the subdomain’s primary server configured in the parent domain is valid and matches the information configured in the subdomain.

Cause: The resolv.cfg file (or equivalent) of the host does not contain the correct domain name or name server address.

Solution: Specify the correct domain name or name server address in the hosts’s resolv.cfg file (or equivalent).

Cause 1: The root name server information is invalid; therefore, the root servers are unreachable. For non-eDirectory systems running DNS, changes to this information are not automatically propagated through a domain; you must enter the changes manually.

Solution 1: Verify that the IP addresses of the root name servers configured in the RootServerInfo zone are correct. The most recent update of root name server information is available through FTP at ftp://rs.internic.net/domain/named.root.

Cause 2: The hostname or IP address was not resolved because the delegation to the zone is incorrect.

Solution 2: Configure the correct hostname or IP address information for the zone in eDirectory.

Cause 3: The hostname or IP address was resolved to the wrong value.

Solution 3: Change the hostname or IP address information for the zone to the correct value in eDirectory.

Cause 4: The name server information of the primary name server of the domain is incorrect or missing in the root name servers.

Solution 4: Verify that the domain is properly registered with the INTERNIC, which is the organization that configures the name server information of the domain.

Cause 5: The name server for the domain is down or is unreachable.

Solution 5: Use the ping utility to locate the connectivity problem. If the problem exists in your domain, make the necessary repairs to restore connectivity.

Cause 6: The root name server for the domain is down or is unreachable.

Solution 6: Use the ping utility to locate the connectivity problem. If the problem exists in your domain, make the necessary repairs to restore connectivity.

Cause 7: You do not have sufficient rights to access the zone.

Solution 7: Contact the network administrator for the zone and obtain sufficient rights to access the zone.

Cause 1: The Zone SOA serial number is not automatically updated after the change is made.

Solution 1: After you modify the Resource Record, change the Zone SOA serial number manually.

Cause 2: The server cache is not automatically refreshed after changes are made.

Solution 2: Unload the named.nlm module and reload it to refresh the DNS server settings.

Cause: The DHCP server object is not properly configured.

Solution: Make sure you have created the DHCP server object, and at least one Subnet object and Subnet Address Range object each. Verify that when you load the DHCP server module, dhcpsrvr.nlm, a message from the NetWare^® system console indicates that the IP database is loaded

Cause 1: Frequently changing the server roles to passive primary from designated secondary.

Solution 1: Do not change the server roles to passive primary from designated secondary when the server is running. Although the server can recognize the changes in roles, there are some issues in synchronizing these roles.

Cause 2: The dynamic reconfiguration interval is not set properly.

Solution 2: Make sure that the dynamic reconfiguration interval is not set too high (20-24 hours) because this slows down the synchronizing mechanism. Also, setting this interval very low (less than 10 minutes) slows down the DNS query/update/transfer mechanism. The recommended value for this option is 15 minutes. The dynamic reconfiguration interval can be set through the management utilities.

Cause: The value for the update filter is not set properly.

Solution: Set the ACL value of the update filter to the IP address of the DHCP server, or set the value to any. The value is set to none by default and all dynamic updates are refused by the DNS server. This can be set through the management utilities.

Cause: A reverse (IN-ADDR.ARPA) zone does not exist for the corresponding forward zone update.

Solution: Verify that the reverse (IN-ADDR.ARPA) zone exists for the corresponding forward zone update. The logic for a Novell update is to first create/update the data (PTR resource record) in the reverse zone and then create the corresponding A record in the forward zone. If the reverse zone does not exist, the response is negative for a dynamic update request.

Cause: The notify and transfer-format values are not set properly.

Solution: Ensure that the value for the notify option is set to Yes and the value for the transfer-format option is set to one-answer in the primary server (older versions of DNS servers support only the one-answer format of zone transfer).

Cause 1: The address list in the query filter option is not configured properly.

Solution 1: Ensure that this attribute is configured properly in the DNS server and the DNS zone (the value specified in the DNS zone overrides the value specified in the DNS server). If this attribute is not set with any value, the default behavior of the server is to allow queries from all hosts. Ensure that the address of the specific client (the client that has requested the server) is set explicitly so that the address falls in an address range as specified in this attribute, or that the attribute value is set to any.

Cause 2: A query from a client fails because the client is unrecognized.

Solution 2: Ensure that the address of this client is not listed in the Blacklist server attribute.

Cause: The DNS server is not registered with a valid IP address and port.

Solution: Make sure that the IP address and port combination allocated for the DNS server does not conflict with any other services running on the NetWare server.

Cause: ncssdk.nlm is not loaded on the NetWare server (this NLM™ provides all of the required APIs for cluster support).

Solution: Load the ncssdk.nlm by entering NCSSDK at the server console.

Cause: The DNS-DHCP schema DNS-DHCP base objects (Locator, DNS-DHCP Group, RootServerZone Info) does not exist in eDirectory.

Solution: Extend the DNS-DHCP schema and create the base objects in eDirectory by entering DNIPINST at the server console.

Cause: Memory-intensive operations such as deleting a large zone, deleting a large number (1000 or more) of zones at the same time, or deleting 1,0,00,000 or more resource records at the same time.

Solution: Wait for a period of time to let these long operations complete. Use the ndstrace utility to track these operations. If no changes occur, click the Refresh button on the browser.

Cause: The display settings or resolution are not correct on the client's machine.

Solution: The typical screen resolution for running the DNS/DHCP iManager utility is 1024 x 768 or more.

Cause: The display settings or resolution are not correct on the client's machine.

Solution: The minimum screen resolution for running the DNS/DHCP Java-based console is 600 x 800 with at least 256 colors.

Cause: There is no support for Forward Zones in Java-Based Management.

Cause :The reason could be eDirectory errors. For instance, the Remote eDirectory could be down when the DNS server tries to get zone data.

Solution: No action is required. The DNS server automatically recovers after eDirectory access is restored.

Cause: This error is caused because of a heavy load during zone in. The error message is displayed on the designated secondary server.

Solution: This error message is informational and can be ignored. The server continues to function normally.