[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference help::dns

Title:	DECdns - Digital's Distributed Name Service
Notice:	not to be confused with DNS: Domain Name Service (Kits: 1420,947))
Moderator:	BULEAN::WHEATER

Created:	Tue Apr 14 1987
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1443
Total number of notes:	5833

1431.0. "Fixing a clearinghouse whos address changed?" by GADWAL::W_MCGAW () Wed Feb 26 1997 20:08

    Hi,
    
    I have a customer that has an 8 DNS server namespace where all servers
    are connected via wide area connections.  One of the DNS servers
    addresses changed from 37.7 to 30.7 but the steps for changing the
    address were not followed.  The problem now is that the DNS clerk cache
    for the remaining servers still show the old address for the
    clearinghouse (onc007_ch).  The customer tried stopping the server and
    clerk processes, deleting the clerk cache files and rebooting.  When it
    came back up, it appears that it learned the onc007_ch address from one
    of the other servers and loaded it back incorrectly.
    
    My question is:
    
    How can this be fixed without having to perform the above procedure on
    all DNS servers simultaneously?  Can it be done?
    
    Thank you for any help.
    
    Walt McGaw
    Digital Network Services Unit
    USCSC/CS
    (719)282-9442

T.R	Title	User	Personal Name	Date	Lines
1431.1	Forgot to add this is V2 DNS.	GADWAL::W_MCGAW		`Thu Feb 27 1997 13:03`	6
	Hi, I forgot to mention an important fact that these servers are all DECnet/OSI nodes running DNS V2. Walt
1431.2	purge cache	DRAGNS::WHEATER		`Thu Feb 27 1997 13:49`	4
	Try purging the clerk cache - use decnet_loc_register , option 6 to purge the cache. -Bob Wheater
1431.3	tried deleting cache files already but no success	GADWAL::W_MCGAW		`Thu Feb 27 1997 19:10`	13
	Hi Bob, The customer tried stopping the server and clerk processes, deleted the cache files and rebooted the node. It still came up with the remote clearinghouses incorrect address (we believe from one of the other servers in the namespace). Should we try option #6 on each node as close to simultaneous as possible to completly remove it's entry from the namespace and then try using DNS$CONFIGURE to connect ot an off lan server? Thank you, Walt McGaw
1431.4		MUNICH::KLOEPPER	Vera Kloepper/Net&Comms-Support	`Mon Mar 03 1997 09:48`	36
	Hi ! As far as I've seen this ... this isn't a cache problem at all, but an access-control problem. For sure you have decnet events on your dns-master node showing authentication failures. When I give a DNS Server node a new address I first change the registration of this node and add the two new towers (plus the backtranslation softlink) to the Namespace. If this is done before the DNS server is rebooted with the new address - the DNS Server will change the dna$towers attribute of the clearing- house object during startup of the server. As soon as this object is changed the skulk will "repair" the dns$replicas attribute of the skulked directories. If you do this after the DNS Server reboot - and the backtranslation directories are NOT replicated to this changed server .. the next boot will do the expected job. If your backtranslation directories are replicated to this DNS server ... the easiest way to get the Server running is : a) boot the server with the old address b) skulk the root (or the ch-parentdirectory) c) use decnet_register to add a third and fourth tower (NSP/TP4 new address) d) skulk the two used backtranslation directries e) reboot the DNS Server with its new address regards Vera p.s. It makes no sense to change the access control in your namespace - you will need several wildcard entries with all rigths for sensible information - not to good ;-)