Conference azur::mcc

6005.0. "DECnet OSI V5.1A DNS/MCC patch possible problem" by TOOK::SMARTIN () Tue May 24 1994 17:30

If you are running DECnet OSI V5.1A on ULTRIX and have applied the MCC
patch for DNS which puts a hybrid clerk on your system, this message may
be of interest to you either now, or at some point in the future.

At some point in time something happens which causes the DNS clerk software
(or some stored data...) to be unable to contact an off-LAN nameserver.
This is an option in the menu within the dnsconfigure script. (Make a
connection to an off-Lan nameserver).

This is not a problem until your DNS clerk cache becomes empty.
(This usually happens when someone deletes the clerk cache files
/var/dss/dns/dns_cache.*)

SYMPTOMS:
---------

At this point you will notice symptoms in MCC of untranslated un-mappable
DNS errors when you do a
MCC>dir domain *
or any other command that must touch DNS data.

If you try the following and get 'cannot contact a nameserver'
#dnscp
dns>dir child .*
or any other dnscp command that contacts the nameserver for information

Check and see if the cache is empty:

DNS>show dns clerk cache

(its empty if all you get is a half dozen title lines with *'s in them.)

When the dnsclerk cannot contact a nameserver it is a sign that you need
to connect to an off-lan nameserver.

The next step is to try and get contact with an off-lan nameserver using
the DNS Configure utility.  You will need to know the nsap of the 
nameserver in the %x49..... form.  This can be obtained by running
dnsconfigure on the nameserver itself and selecting the 'show' local
information menu item.
Then back on the damaged system, run dnsconfig and select the connect to
an off-Lan nameserver and enter the nameserver's NSAP obtained above.
When you try that, and if you have typed the correct NSAP address and still
get the answer that the nameserver is not advertising, then you 
HAVE THE PROBLEM discussed in this note.
================

THE WORKAROUND:
---------------

What the damaged system is trying to obtain is a cache entry.  The process
of contacting an off-lan nameserver can be circumvented by supplying a
viable cache to the damaged system.  The cache lives in /var/dss/dns in
the dns_cache.* files.  The dns_cache.version_number file contains the
actual version number of the current cache.  The cache file you copy in,
should be as simple as possible.  It should only contain one entry - the
address of the remote nameserver.

ACQUIRING A CLEAN CACHE FILE

	o from either DNSCP or NCL on a system that is currently working:

		o disable dns clerk
		o delete dns clerk

	o cd /var/dss/dns

		o locate files:
		  dns_cache.version & dns_cache.some-number (ex:
							    0000000020)

	o rename these files to something else (but maintain the version
	  number extension value, either in the filename or on paper.)
	
	o from either DNSCP or NCL:
          (startup with no file, creates an empty cache)
		o create dns clerk
		o enable dns clerk

	o run dnsconfigure and enter the address of the root server
		o this creates new cache file (is that
		  dns_cache.version?)

	o from either DNSCP:
		o dump dns clerk cache
		  (and ensure that you have only one entry)
		o disable dns clerk
		o delete dns clerk
		  (stopping the clerk writes out the cache file)

	o rename new cache file to something else for later use on a
	  damaged system.

	o rename original 2 files to their original names

	o use newly created file to fix other systems with a problem
	  contacting a off-lan DNS server. Place the two cache files
	  in /var/dss/dns instead of the existing (empty) cache files.
	  Ensure that the version number in the dns_cache.version_number
	  matches the extension of the dns_cache.number file.