This section provides the following troubleshooting information for DNS:
If you experience problems related to DNS or TCP/IP, you can use the following steps to begin troubleshooting.
If you do not receive a response, your client's TCP/IP stack is not functioning. One of the following problems might be the cause:
If this approach fails, one of the following conditions might be the cause:
If this approach fails but the preceding steps were successful, the problem is probably related to your router or your client's default router. If you are using DHCP, the default router configured for the DHCP server for each client is probably incorrectly configured.
If this approach fails, the default DNS server configured for your TCP/IP stack is invalid, or the DNS server is not functioning. If you are using DHCP, the DNS server that is configured on the DHCP server is not properly configured.
If this approach fails, your company's DNS server (that forwards DNS requests to the Internet) is not functioning, or the Internet DNS server to which your DNS server forwards requests is not functioning.
In addition to using ping to troubleshoot DNS configuration problems, you can also use the NSLOOKUP utility at your server. For information on using this utility, see NSLOOKUP in Utilities Reference.
If you experience problems with DNS, check the following configuration problems.
Internet RFC 1912 provides information about common operational errors found in both the operation of DNS servers and the data the DNS servers contain. The following list describes the most common operational errors that occur.
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 eDirectoryTM-based DNS 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 eDirectory-based DNS. If the primary server is not eDirectory-based, you might need to change the serial number manually for the secondary server to recognize that a change has occurred.
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 further information, refer to RFCs 1537 and 1713.
Cause 2---The host is down or is unreachable.
Solution 2---Use PING 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 enter 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---Enter 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, 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 PING 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 PING 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 modification is made.
Solution 1: After you modify the Resource Record, change the Zone SOA serial number manually.
Cause 2: The server cache is not atomically refreshed after modifications 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, at least one Subnet object, and one Subnet Address Range object. 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.
This section provides assistance for those troubleshooting TCP/IP problems on Windows 95* clients. You should have a basic understanding of TCP/IP and how it is configured for Windows 95.
The WINIPCFG utility displays a client's current TCP/IP configuration. To execute this utility, click Start > Run, enter winipcfg, and click Enter.
If the client's IP address was statically assigned and configured, the information that was entered under TCP/IP Protocols in the control panel's Network settings is displayed.
If the client was configured to obtain an address using DHCP, the information displayed was received from the DHCP server that assigned the IP address.
WINIPCFG provides the following information about the client:
If the client has obtained an address from a DHCP server, click More Info to identify the DHCP server, when the lease began, and when it expires. Four additional buttons provide the following functions:
If you want another IP address to be assigned to the client, select RELEASE, then select RENEW.
PING is the most basic utility available to test, verify, and troubleshoot TCP/IP connectivity within a network. PING sends an ICMP packet to a specific host with a small amount of data and expects that host to respond with the same data packet. If you receive a response, both TCP/IP and connectivity between the two hosts are operational. If you do not receive a response, one of the following conditions exists:
To run PING, from a DOS prompt enter the command followed by a hostname or IP address, such as the following:
C:\> ping www.novell.com >
If TCP/IP is operational and connectivity exists between the hosts, you will receive the following type of response:
Pinging www.novell.com [137.65.2.5] with 32 bytes of data:Reply from 137.65.2.5: bytes=32 time=27ms TTL=59Reply from 137.65.2.5: bytes=32 time=22ms TTL=59Reply from 137.65.2.5: bytes=32 time=31ms TTL=59
If you use the IP address of the host, you will receive the same type of reply.
Using the host's domain name is a good way to determine the host's IP address, and doing so also causes the client to request DNS name resolution before sending the ICMP packet. This approach is an excellent way to determine if DNS name resolution is working. If it is not working, you will receive a message such as the following:
Unable to resolve www.novell.com.
If DNS name resolution is not working, one of the following conditions might be the cause:
The PING command has the following syntax:
ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [[-j host] | [-k host-list]] [-w timeout] destination list
Table , PING Options explains the use of the PING options.
Table . PING Options
NOTE: You can find unauthorized addresses in an exported DHCP configuration by searching for IP Address objects with an Assignment Type value of 32. Use FIND in a text editor to quickly identify addresses that have been marked as unauthorized.
TRACERT can be very useful when you are resolving network-wide TCP/IP problems. TRACERT traces the route to a specific host and displays all hops that occur to search for the target host.
To run TRACERT, from a DOS prompt enter the command followed by a hostname or IP address, such as the following:
C:\> tracert www.novell.com
The TRACERT command has the following syntax:
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name
Table , TRACERT Options explains the use of the TRACERT options.
Table . TRACERT Options
ARP is an advanced utility that should be used only by those who have a detailed understanding of TCP/IP and must troubleshoot complex problems. The ARP command enables you to display and modify the ARP cache of a client.
Following are three examples of use of the ARP command:
ARP -s inet_addr eth_addr [if_addr]ARP -d inet_addr [if_addr]ARP -a [inet_addr] [-N if_addr]
Table , ARP Options explains the use of the ARP options.
Table . ARP Options
NETSTAT is an advanced utility that should be used only by those who have a detailed understanding of TCP/IP and must troubleshoot very complex problems. NETSTAT displays protocol statistics and current TCP/IP network connections.
The NETSTAT command has the following syntax:
NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval]
Table , NETSTAT Options explains the use of the NETSTAT options.
Table . NETSTAT Options
If you suspect that a LAN card is malfunctioning, use the -e option while troubleshooting. The -e option displays Ethernet statistics, including discards and errors.
The -a option provides a detailed display of the active TCP connections of the port number and network host communicating with that port. This information is useful when you are attempting to relate TCP port numbers of the various servers with which the client is communicating.
DNIPINST.NLM is a backup method of extending the schema and creating the DNS/DHCP Locator and Group objects and the RootSrvrInfo zone. DNIPINST.NLM can be used if problems occurred during the NetWare® 6 installation process. Most administrators will not need to use this NLM.
You can use the "-F" command line option in the DNIPINST.NLM to re-create the DNS/DHCP configuration objects if the initial attempt to set up Novell® DNS/DHCP Services fails during the configuration object creation stage.
When a failure occurs during the object creation phase, we recommend that you delete the DNS-DHCP (DNS/DHCP Locator), DNSDHCP-GROUP (DNS/DHCP Group), and the RootSrvrInfo objects (if they have been created), then use DNIPINST.NLM with the "-F" flag. When the "-F" command line option is specified, an initial console message confirms the action and the eDirectory login window appears. After a successful login, the object eDirectory context query window is displayed. You can enter the data and create the objects. If a schema extension error occurs, execute DNIPINST.NLM in the regular mode.
The requirement that the DNS and DHCP servers always have access to the DNS/DHCP Locator object has been relaxed.
The DHCP server can load without having access to the DNS/DHCP Locator object. However, the first time the server loads it requires access to the DNS/DHCP Locator object to obtain a copy of any global configuration from the object. The DHCP server saves a copy of the global configuration in SYS:\ETC\DHCP\DHCPLOC.TAB.
In subsequent loads, the DHCP server will try to obtain the global configuration information from the DNS/DHCP Locator object. If the information is not available, the DHCP server will read the information from the last saved copy of SYS:\ETC\DHCP\DHCPLOC.TAB. Each time the DHCP server loads and the DNS/DHCP Locator object is available, the DHCP server updates the DHCPLOC.TAB file.
The DNS server also does not require access to the DNS/DHCP Locator object. It has been enhanced to require access to the DNS/DHCP Locator object only if the NAMED command line arguments are specified to create zones in eDirectory. The DNS server no longer requires access to the RootSrvrInfo zone stored in eDirectory. The DNS server now first tries to find the RootSrvrInfo zone in eDirectory, but if it is not available, the DNS server uses the copy of the information found in SYS:\ETC\DNS\ROOTSRVR.DAT.