15    Testing BIND Servers

In concept, testing BIND servers consists of finding out where information you are looking for is located. In practice, testing BIND servers involves tracing through a network of servers and their databases back to the server responsible for the information. This section provides the tests you use to locate the information.

Appendix I contains a worksheet for you to record information from the various tests. On a copy of the worksheet, write the current server's name, current domain name, and target domain name.

15.1    Glossary

The following terms are used in this section. Refer back to them as needed during the problem solving tests.

authoritative server

A server that stores the information that was requested locally. In contrast, a server that is not authoritative must ask other servers for information about the target host.

current server

The server you are currently logged in to and running tests from.

data types

The types of resource records in the BIND database files. See named(8) for a complete list and explanation.

forwarder

A server that can answer BIND queries from data in its databases and cache, whether or not it is authoritative for the information. Forwarder entries can be in the named.boot file.

nameserver (NS) record

Nameserver records map a domain name to a system that serves the domain, and determine whether a system is familiar with the name servers for the authoritative domain. Nameserver records have the following form:

domain-name IN NS machine-name

On the left is the domain name; on the right is the name of the machine that services the domain.

primary server

A server that stores the main copy of a target domain's databases. If the target host's information is not in the primary server's databases, it does not exist.

secondary server

A server that pulls a copy of the target domain's data from another server. In most cases, the data is pulled from a primary server. However, in some cases, the data is pulled from another secondary server.

start of authority (SOA) record

Start of authority records mark the start of a zone of authority. They occur at the beginning of each master database file. SOA records have the following form:

domain-name IN SOA machine-name

target domain name

The portion of the target host name that begins after the first period (.).

target host

Host name you are trying to resolve. The target domain name is derived from the target host name.

15.2    Starting the BIND Server Testing

To determine if the current server can resolve the target data, complete the following steps:

1. Determine whether the current server can access the target data. Use the following commands:

   #  nslookup
   

   Default Server: host1.corp.com
   Address:  127.0.0.1
   

   >  server localhost
   

   Default Server: localhost.corp.com
   Address:  127.0.0.1
   

   >  set timeout=45
>  set retry=2
>  target_host.target_domain.
   

   If the nslookup command:	Action:
   Succeeds	Go to step 3.
   Fails	If the first time, go to step 2. If the second time, go to Section 15.3.

2. Determine whether the named daemon is running by using the following command:

   #  ps gax | grep named
   

   If the named daemon is:	Action:
   Running	Go to step 1.
   Not running	Start the daemon by using the /sbin/init.d/named start command. If the Internet name service started message appears, go to step 1. If the message is not displayed, this machine is not configured as a BIND server. Decide how the machine should be configured. See Section 6.3 for more information.

3. Log in to the client system and use the nslookup command to try to access the target data.

   If the nslookup command:	Action:
   Succeeds	STOP. The client can resolve the target data.
   Fails	The server knows the information, but is not transferring it to the client. Log out from the client; restart BIND on the server by using the /sbin/init.d/named restart command; log in to the client; and use the nslookup command. If it cannot resolve the target data, you have the wrong server or the BIND server is broken.

15.3    Determining the Server Type

To determine whether the current server is a primary server or a secondary server, complete the following steps:

1. Compare the target domain name with all domain names of the primary and secondary entries in the /etc/named.boot file. These entries have the following form:

   primary domain file
secondary domain [host host...] file

   When directed, record information in the named.boot file section on the worksheet.

   If a named.boot entry:	And the first field is:	Action:
   Matches the target domain name	Primary	Write the server type, domain name, and database file name on the worksheet and go to Section 15.7.
   	Secondary	Write the server type, domain name, database file name, and host IP addresses on the worksheet and go to Section 15.6.
   Is a subset of the target domain name	Primary	Write the server type, domain name, and database file name on the worksheet and go to step 2.
   	Secondary	Write the server type, domain name, database file name, and host IP addresses on the worksheet and go to step 2.
   Neither matches nor is a subset of the target domain name	Primary or secondary	Go to Section 15.4.

   In the following example, the target domain name is zz.bb.cc.:

   #  cat /etc/named.boot
   

   
   .
   .
   .
   
   primary        aa.bb.cc.                              aa.bb.cc.db    [1]
   primary        cc.                                    cc.db        [2]
   secondary      bb.cc.                                 bb.cc.db     [3]
   secondary      zz.bb.cc.                              aa.bb.cc.db    [4]
   
   .
   .
   .
   
   

   1. Not a subset of zz.bb.cc.. [Return to example]

   2. A subset of zz.bb.cc.. The server is primary for cc. domain information and stores the information in the file aa.bb.cc.db. [Return to example]

   3. A subset of zz.bb.cc.. The server is secondary for bb.cc. domain information and stores the information in the file bb.cc.db. [Return to example]

   4. An exact match of zz.bb.cc.. The server is secondary for zz.bb.cc. domain information and stores the information in the file zz.bb.cc.db. Since this is an exact match, you would go to Section 15.6 and perform additional tests. [Return to example]

2. Compare the target domain name with all nameserver (NS) records in the database file recorded on the worksheet. When directed, record information in the Nameservers section on the worksheet.

   Use the following commands to create and view a list of NS records:

   #  grep -n NS database_file > ns_list
#  grep -n ORIGIN database_file >> ns_list
#  sort -n ns_list > ns_list.srt
#  cat ns_list.srt
   

   If any NS record:	And the server is:	Action:
   Contains a longer subset of the target domain name than the domain name on the worksheet	Primary or secondary	The server is neither primary or secondary for the target information. Write the names of the servers on the worksheet and go to step 3.
   Does not contain a longer subset of the target domain name than the domain name on the worksheet	Primary	The database files contain the target information. Go to Section 15.7.
   	Secondary	The database files contain the target information. Go to Section 15.6.

   The following example shows the file created by the preceding commands. The target domain is zz.bb.cc. and the domain name from the worksheet is zz.bb.cc..

   #  cat ns_list.srt
   

   1:$ORIGIN cc.
   10:             IN         NS        server_1.cc.
   17:$ORIGIN cc.
   18:bb           IN         NS        server_3.bb.cc.
   21:$ORIGIN cc.
   22:bb           IN         NS        server_4.bb.cc.
   41:$ORIGIN bb.cc.
   42:zz           IN         NS        server_5.zz.bb.cc.   [1]
   45:$ORIGIN bb.cc.
   46:zz           IN         NS        server_6.bb.cc.    [2]
   

   1. A longer subset (exact match) of the target domain. The domain name from the preceding $ORIGIN line (.bb.cc.) is appended to the domain name of this line zz, resulting in zz.bb.cc.. [Return to example]

   2. A longer subset (exact match) of the target domain. The domain name from the preceding $ORIGIN line (.bb.cc.) is appended to the domain name of this line zz, resulting in zz.bb.cc.. [Return to example]

3. Find the IP addresses in the database file for any name servers on the worksheet. Use the following commands:

   #  grep -n ORIGIN database_file > ip_list
#  grep -n server_name database_file >> ip_list
   

   
   .
   .
   .
   
   

   #  sort -n ip_list > ip_list.srt
#  cat ip_list.srt
   

   Write the IP addresses on the worksheet next to the corresponding server name and go to Section 15.4.

   The following example shows the file created by the preceding commands:

   #  cat ip_list.srt
   

   1:$ORIGIN cc.
   17:$ORIGIN cc.
   21:$ORIGIN cc.
   41:$ORIGIN bb.cc.
   42:zz           IN         NS        server_5.zz.bb.cc.
   43:$ORIGIN zz.bb.cc.
   44:server_5     IN         A         10.140.48.3      [1]
   45:$ORIGIN bb.cc.
   46:zz           IN         NS        server_6.bb.cc.
   47:$ORIGIN bb.cc.
   48:server_6     IN         A         10.12.48.3    [2]
   

   1. The IP address for server_5. [Return to example]

   2. The IP address for server_6. [Return to example]

15.4    Finding the Target Domain Information

To determine which servers the current server communicates with in order to get information for the target domain, complete the following steps:

1. Search the named.boot file and find any forwarder lines. Use the following command:

   #  grep forwarders /etc/namedb/named.boot
   

   When directed, record information in the Forwarders section on the worksheet.

   If your system:	Action:
   Contains a forwarder line	The current server forwards requests. Write the IP addresses for any forwarders on the worksheet and go to Section 15.5.
   Does not contain a forwarder line	The current server does not forward queries. Go to step 2.

2. Compare the target domain name with all nameserver (NS) records in the database file recorded on the worksheet. When directed, record information in the Nameserver section on the worksheet.

   Use the following commands to create and view a list of NS records for each database file:

   #  grep -n NS database_file > ns_list
#  grep -n ORIGIN database_file >> ns_list
#  sort -n ns_list > ns_list.srt
#  cat ns_list.srt
   

   If any NS record:	And:	Action:
   Contains a longer subset of the target domain name than the domain name on the worksheet	->	Write the names of the servers on the worksheet and go to step 3.
   Does not contain a longer subset of the target domain name than the domain name on the worksheet	The Nameserver section on the worksheet is blank	Section 15.8.

3. Find the IP addresses in the database file for any name servers on the worksheet. Use the following commands:

   #  grep -n ORIGIN database_file > ip_list
#  grep -n server_name database_file >> ip_list
   

   
   .
   .
   .
   
   

   #  sort -n ip_list > ip_list.srt
#  cat ip_list.srt
   

   Write the IP addresses on the worksheet next to the corresponding server name and go to step 4.

4. Verify whether each server listed in the Nameserver section on the worksheet is reachable by using the ping command.

   If a server:	And:	Action:
   Responds to the ping command	You have root access to the server	The server is reachable and under your administrative control. Note both items on the worksheet. Go to step 5.
   	You do not have root access to the server	The server is reachable, but not under your administrative control. Note both items on the worksheet. Go to step 5.
   Does not respond to the ping command	->	Note this on the worksheet. If no servers responded to the ping command, STOP. The current server is isolated from its servers on the network. You cannot solve the problem; contact your enterprise network administrator.

5. Log in to each reachable server by using the telnet command. Each server you log in to becomes the current server. Get a new worksheet and write the current server name, current domain name, and target domain name on it. Go to Section 15.2.

15.5    Testing the Forwarders

To determine whether the forwarders prevent you from resolving the target host name, complete the following steps:

1. Determine whether each forwarder listed on the worksheet is reachable by using the ping command.

   If a forwarder:	And:	Action:
   Responds to the ping command	You have root access to the forwarder	The forwarder is reachable and under your administrative control. Note both items on the worksheet. Go to step 2.
   	You do not have root access to the forwarder	The forwarder is reachable, but not under your administrative control. Note both items on the worksheet. Go to step 2.
   Does not respond to the ping command	->	Note this on the worksheet. If no forwarders responded to the ping command, STOP. The current server is isolated from its forwarders on the network. You cannot solve the problem; contact your enterprise network administrator.

2. Edit the named.boot file and eliminate any forwarders that did not respond to the ping command.

3. Enter the nslookup command again for the target host.

   If the nslookup command:	Action:
   Succeeds	Go to step 4.
   Fails	Go to step 5.

4. Edit the named.boot file and add the forwarders removed in step 2 at the end of the forwarders line. In addition, contact the administrators of forwarders not under your administrative control and inform them that they might have a problem with their forwarder. STOP.

5. Log in to each reachable forwarder by using the telnet command. This forwarder is now the current server. Get a new worksheet and write the current server name, current domain name, and target domain name on it. Go to Section 15.2.

   If the forwarder or other machines:	Action:
   Cannot resolve the target name	Remove the forwarder from named.boot file.
   Can resolve the target name	STOP.

15.6    Testing Secondary Authoritative Servers

To determine whether the secondary server has the information you want, complete the following steps:

1. Find the database serial number in the start of authority record in the database file. Use the following command:

   #  head -4 database_file
   

   Write the first number on the worksheet in the named.boot section. This is the serial number. If you have a serial number on a previous worksheet, compare the current serial number with that one. If the current number is larger, write "newer" on the worksheet. If it is smaller, write "older."

   In the following example, 23 is the serial number:

   #  head -4 database_file
   

   $ORIGIN cc.
   bb          IN        SOA        host1.bb.cc. postmaster.host1.bb.cc. (
               23 300 60 1209600 43200 )
               IN        MX         100 host1.bb.cc.
   

2. Determine whether the target data is contained in the database file written on the worksheet. Use the following commands to create and view a list of resource records:

   #  grep -n data_type database_file > ns_list
#  grep -n ORIGIN database_file >> ns_list
#  sort -n ns_list > ns_list.srt
#  cat ns_list.srt
   

   If the database file:	And the serial number is:	Action:
   Contains the target data	Newer	The data exists in the domain. Go to step 3.
   Contains the target data	Older or same	The server is broken, or you made a mistake. Recheck all steps up to this point.
   Does not contain the target data	->	The data does not exist in the domain. Go to step 4.

3. Determine whether the current server can access the target data. Use the following commands:

   #  nslookup
   

   Default Server: host1.corp.com
   Address:  127.0.0.1
   

   >  server localhost
   

   Default Server: localhost.corp.com
   Address:  127.0.0.1
   

   >  set timeout=45
>  set retry=2
>  target_host.target_domain.
   

   If the nslookup command:	And the database serial number is:	Action:
   Succeeds	->	STOP. The server is working. Either the client or server cannot communicate with this server, or this server just started working.
   Succeeds	Newer	Log out of the secondary server. Get the previous secondary server's worksheet and go to step 8.
   Fails	->	Restart the current secondary server by using the /sbin/init.d/namedrestart command. Then use the nslookup command again.

4. Verify whether each name server listed on the worksheet is reachable by using the ping command.

   If a server:	And:	Action:
   Responds to the ping command	You have root access to the server	The server is reachable and under your administrative control. Note both items on the worksheet.
   	You do not have root access to the server	The server is reachable, but not under your administrative control. Note both items on the worksheet.
   Does not respond to the ping command	->	Note this on the worksheet. If no servers responded to the ping command, STOP. The current server is isolated from its servers on the network. You cannot solve the problem; contact your enterprise network administrator.

   Count the number of servers that responded to the ping command and that are under your administrative control. If the number is zero (0), go to Section 15.9.

5. Edit the named.boot file and find the secondary entry. Delete the IP address for those servers that are not reachable and are not under your administrative control. Delete those entries from the worksheet as well.

6. Log in to each reachable server by using the telnet command. Start a new worksheet for each server, writing the server name as the current server. Save the old worksheet.

7. Compare the target domain name with all domain names of the primary and secondary entries in the /etc/named.boot file. These entries have the following form:

   primary domain file
secondary domain [host host ...] file

   When directed, record information in the named.boot file section on the worksheet.

   If a named.boot entry:	And the first field is:	Action:
   Matches the target domain name	Primary	Write the domain name and database file name on the worksheet and go to Section 15.7.
   	Secondary	Write the domain name, host IP addresses, and the database file name on the worksheet and go to step 1.
   Is a subset of the target domain name	->	STOP.
   Neither matches nor is a subset of the target domain name	->	STOP.

8. Restart the current secondary server by using the following command:

   #  /sbin/init.d/named restart
   

   After restarting, wait a few minutes before proceeding to the next step. This allows for the database to be updated.

9. Determine whether the current server can access the target data. Use the following commands:

   #  nslookup
   

   Default Server: host1.corp.com
   Address:  127.0.0.1
   

   >  server localhost
   

   Default Server: localhost.corp.com
   Address:  127.0.0.1
   

   >  set timeout=45
>  set retry=2
>  target_host.target_domain.
   

   If the nslookup command:	Action:
   Succeeds	STOP. If you are in a telnet session to another secondary server, log out. Go to step 8.
   Fails	If you just ended a telnet session to another server, go to step 10. If you did not end a telnet session, either the current server is broken and cannot read the database file, or you made an error. Check all steps up to this point.

10. Compare the database serial number of the current server with the database serial number of the server from which you just logged out. Use the following command:

    #  head -4 database_file
    

    If the current database serial number is:	Action:
    Older	Either the server cannot pull the database from the authoritative server, or you made a mistake. Check all steps up to this point.
    The same	The serial numbers cannot be equal. Check all steps up to this point.

15.7    Testing Primary Authoritative Servers

To determine whether the primary server has the information you want, complete the following steps:

1. If you are in a telnet session from a secondary server to a primary, go to step 2. Otherwise, go to step 3.

2. Find the database serial number in the start of authority record in the database file. Use the following command:

   #  head -4 database_file
   

   Write the first number on the worksheet in the named.boot section. This is the serial number. If you have a serial number of a previous worksheet, compare the current version number with that one. If the current number is larger, write "newer" on the worksheet. If it is smaller, write "older." If it is equal, write "same."

   In the following example, 23 is the serial number:

   #  head -4 database_file
   

   $ORIGIN cc.
   bb          IN        SOA        host1.bb.cc. postmaster.host1.bb.cc. (
               23 300 60 1209600 43200 )
               IN        MX         100 host1.bb.cc.
   

3. Determine whether the target data is contained in the database file written on the worksheet. Use the following commands to create and view a list of resource records:

   #  grep -n data_type database_file > ns_list
#  grep -n ORIGIN database_file >> ns_list
#  sort -n ns_list > ns_list.srt
#  cat ns_list.srt
   

   If the database file:	Action:
   Contains the target data	The data exists in the domain. Go to step 4.
   Does not contain the target data	The data does not exist in the domain. Go to step 5.

4. Determine whether the current server can access the target data. Use the following commands:

   #  nslookup
   

   Default Server: host1.corp.com
   Address:  127.0.0.1
   

   >  server localhost
   

   Default Server: localhost.corp.com
   Address:  127.0.0.1
   

   >  set timeout=45
>  set retry=2
>  target_host.target_domain.
   

   
   

   If the nslookup command:	And the database serial number is:	Action:
   Succeeds	->	STOP. The server is working. Either the last server cannot communicate with this server, or this server just started working.
   Succeeds	Older or same	STOP. The server is broken, or you made a mistake. Check all steps up to this point.
   Succeeds	Newer	Log out of the primary server. Get the previous secondary server's worksheet and go to Section 15.6, step 8.
   Fails	->	Restart the current primary server by using the /sbin/init.d/namedrestart command. Then try the nslookup command again.

5. Edit the database file and increment the database serial number by 1 to age the database. The following example shows the SOA record before and after editing. Note the serial number increase from 23 to 24.

   #  head -4 database_file
   

   $ORIGIN cc.
   bb          IN        SOA        host1.bb.cc. postmaster.host1.bb.cc. (
               23 300 60 1209600 43200 )
               IN        MX         100 host1.bb.cc.
   

   #  vi database_file
   

   
   .
   .
   .
   
   

   #  head -4 database_file
   

   $ORIGIN cc.
   bb          IN        SOA        host1.bb.cc. postmaster.host1.bb.cc. (
               24 300 60 1209600 43200 )
               IN        MX         100 host1.bb.cc.
   

6. Edit the database file and add new data to the database. Refer to Section 15.1 for information on valid data types. Database fields are separated by a tab character. Be sure to precede any new entry with a $ORIGIN entry. The following example shows a new address record for host host1.bb.cc:

   $ORIGIN bb.cc
   host1            IN        A           16.141.112.11
   

7. Restart the primary server by using the following command:

   #  /sbin/init.d/named restart
   

8. Determine whether the current server can access the target data. Use the following commands:

   #  nslookup
   

   Default Server: host1.corp.com
   Address:  127.0.0.1
   

   >  server localhost
   

   Default Server: localhost.corp.com
   Address:  127.0.0.1
   

   >  set timeout=45
>  set retry=2
>  target_host.target_domain.
   

   If the nslookup command:	Action:
   Succeeds	Log out of the primary server. Get the previous secondary server's worksheet and go to Section 15.6, step 8.
   Fails	Either the server is broken, or you made a mistake. Check all steps up to this point.

15.8    Tracing Information from the Root Name Server

To resolve the target name beginning with the root of the BIND namespace, complete the following steps:

1. Determine whether the current server has a cache file containing the information necessary to find a root server. Use the following command:

   #  grep cache /etc/named.boot
   

   If a cache line:	Action:
   Does not exist	The current server cannot contact a root name server. Note this on the worksheet and go to step 2.
   Exists	Note this on the worksheet and go to step 3.

2. Add a cache file to your server.

   Caution

   This step alters many system files. Perform the steps as shown to ensure the correct operation of your system.

   1. Create copies of specific BIND and system files. Enter the following commands:

      #  cd /etc
#  cp -r namedb namedb.back
#  cp rc.config rc.config.back
#  cp hosts hosts.back
#  cp resolv.conf resolv.conf.back
#  cp svc.conf svc.conf.back
#  cd /var/adm/sendmail
#  cp sendmail.cf sendmail.cf.back
      

   2. Display the name of the local host by using the hostname command. You will need to set this again after running the BIND Configuration application.

   3. Run the BIND Configuration application. (See Section 6.3.) Modify the configuration and create a caching server. Do not start the BIND daemon automatically and do not run svcsetup.

   4. Copy the system files back to the /etc directory. Use the following commands:

      #  cd /etc
#  cp rc.config.back rc.config
#  cp hosts.back hosts
#  cp resolv.conf.back resolv.conf
#  cp svc.conf.back svc.conf
      

   5. Set the host name back to the original host name by using the hostname command.

   6. Copy the sendmail file back to the /var/adm/sendmail directory and restart sendmail.

      #  cd /var/adm/sendmail
#  cp sendmail.cf.back sendmail.cf
#  /sbin/init.d/sendmail restart
      

   7. Copy the BIND files back to the /etc directory. Use the following commands:

      #  cd /etc
#  cp namedb/namedb.boot namedb.back/named.boot_new
#  cp namedb/namedb.ca namedb.back
#  rm -rf namedb.back namedb
#  mv namedb.back namedb
#  cd namedb
      

   8. Edit the named.boot file and add the following two lines to the end of the file:

      ;
      cache            .                    named.ca
      

   9. Remove the named.boot_new file.

   10. Restart the current server by using the /sbin/init.d/named restart command.

3. Display the named.ca file by using the following command:

   #  cat named.ca
   

   Write the root name server names and their IP addresses in the Root nameservers section on the worksheet.

4. Verify whether each root name server listed on the worksheet is reachable by using the ping command.

   If a root name server:	Action:
   Responds to the ping command	Note this on the worksheet. Go to Section 15.10.
   Does not respond to the ping command	Note this on the worksheet. If no servers responded to the ping command, go to step 5.

5. Do either of the following:

   • Give the current server access to the Internet. Then restart the named daemon by using the following command:

     #  /sbin/init.d/named restart
     

     Keep the same current server and worksheet, and go to Section 15.2.

   • Add a forwarder entry to direct the current server to communicate with a machine with access to the Internet. Then restart the named daemon by using the following command:

     #  /sbin/init.d/named restart
     

     Keep the same current server and worksheet, and go to Section 15.2.

15.9    Resolving Target Data

To resolve target data using a name server, complete the following steps:

1. Try the nslookup command for the target system. Pick the first nameserver from either the Root nameserver section or the Nameserver section. Use the following commands:

   current_server>  nslookup
   

   Default Server:  localhost.zk3.dec.com
   Address:  127.0.0.1
   

   >  server IP_address
Default Server:  [ IP_address]
Address:  128.102.16.10
>  set type data_type
>  target_name
   

   If the nslookup command:	And:	Action:
   Succeeds	->	STOP. The server is working. Either the last server you checked out does not talk to this one or this server just started working. Recheck all steps completed up to this point.
   Fails	An error message is returned.	If a "non-existent domain" message displays, no data exists for the target_name. Go to Section 15.10. If a "no information available" message displays, the target_name exists, but the information you want is not associated with it. If this information should exist, contact the target domain administrator. If a "timed-out" message displays, the server to which you sent the query cannot contact the server that knows the information. Go to step 2.
   Fails	An error message is not returned.	An unknown error. Contact the target domain administrator.

2. Modify the retry and timeout values and try the nslookup command again. Enter the following commands:

   current_server>  nslookup
   

   Default Server:  localhost.zk3.dec.com
   Address:  127.0.0.1
   

   >  server IP_address
Default Server:  [ IP_address]
Address:  IP_address
>  set type data_type
>  target_name
   

   If the nslookup command:	And:	Action:
   Succeeds	->	STOP. The server is working, but is slow. This might prevent the query from being resolved. Check the network connection to the server. If that is correct, wait for the performance to improve. If it does not improve, contact the name server administrator.
   Fails	An error message is returned.	If a "non-existent domain" message displays, no data exists for the target_name. Go to Section 15.10. If a no information available message displays, the target_name exists, but the information you want is not associated with it. If this information should exist, contact the target domain administrator. If a "timed-out" message displays, the server to which you sent the query cannot access the server that knows the information. Select another nameserver from the worksheet and go to step 1.
   Fails	An error message is not returned.	An unknown error. Contact the target domain administrator.

15.10    Finding the First Nonexistent Domain

To find the first nonexistent domain in a target name, complete the following steps:

1. Use the nslookup command, using the smallest subset of the target domain name. Enter the following commands:

   current_server>  nslookup
   

   Default Server:  localhost.zk3.dec.com
   Address:  127.0.0.1
   

   >  server IP_address
Default Server:  [ IP_address]
Address:  IP_address
>  set type=ns
>  target_name_subset
   

   For example, if the target domain name is zz.bb.cc., the first attempt would be to resolve the target name subset cc.. If necessary, the second attempt would use bb.cc.. The third, zz.bb.cc..

   If the nslookup command:	And:	Action:
   Succeeds	->	Go to step 3.
   Fails	An error message is returned.	If a "non-existent domain" message displays, no data exists for the target_name. If the information should exist, contact the domain administrator and request that the information be added to the domain. STOP. If a "timed-out" message displays, go to step 2. This should not happen because the server worked well before.

2. Modify the retry and timeout values and try the nslookup command again. Enter the following commands:

   current_server>  nslookup
   

   Default Server:  localhost.zk3.dec.com
   Address:  127.0.0.1
   

   >  server IP_address
Default Server:  [ IP_address]
Address:  IP_address
>  set retry=2
>  set timeout=45
>  set type=ns
>  target_name_subset
   

   If the nslookup command:	And:	Action:
   Succeeds	->	Go to step 3.
   Fails	An error message is returned.	If a "non-existent domain" message displays, no data exists for the target_name. If the information should exist, contact the domain administrator and request that the information be added to the domain. STOP. If a "timed-out" message displays, select another name server from the worksheet and go to Section 15.9.

3. Add the next part of the target domain name to the target subset and go to step 1.