Runaway named process

[Scott R. Presnell]

srp at babar.mmwb.ucsf.edu (I) write:

>Hi folks.

>	I've got a curious problem with the name service that I can't seem
>to pin down. So I thought I'd ask to see if anyone else is having this
>problem.
>Over the last week, I've had several cases of the named process "running
>away:" gaining inordinate amounts of CPU time (in the thousands of minutes

Just in case someone else runs into this, I'll answer my own question.
Turns out that I got hit by the bogus root nameservers that are making the
rounds. If you see these guys in a named_dump.db of named, you've been hit
too.

; Dumped at Fri Nov 16 08:58:43 1990
; --- Cache & Data ---
$ORIGIN .
.	602116	IN	NS	NS.NIC.DDN.MIL.

[...]
	18376	IN	NS	TELECOM.	; bad - does not exist
	18352	IN	NS	NEXTSVR.	; bad
	18352	IN	NS	MTECV1.		; bad
;
;

The affected hosts were secondary servers that forwarded requests.  My
fix was two fold:

	1) Don't be a named that forwards requests to a specific host (that,
	in my case, caused the cache to become contaminated).  

	2) You may also want to get bind4.8.3 from ucbarpa.Berkeley.EDU 
	(ha, ha, they lost!) and install the named part.  It takes no
	effort to get it up on the SGI, and because you have the source,
	you can insert code to warn you of cache changes and zone updates.
	It's also a more recent version than the one SGI ships.
	
	I'd be glad to help if anyone else bumps into this problem.

	- Scott Presnell
--
Scott Presnell				        +1 (415) 476-9890
Pharm. Chem., S-926				Internet: srp at cgl.ucsf.edu
University of California			UUCP: ...ucbvax!ucsfcgl!srp
San Francisco, CA. 94143-0446			Bitnet: srp at ucsfcgl.bitnet