Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!agate!ucbvax!ucsfcgl!babar.mmwb.ucsf.edu!srp From: srp@babar.mmwb.ucsf.edu (Scott R. Presnell) Newsgroups: comp.sys.sgi Subject: Re: Runaway named process Keywords: resolver, name service, named, runaway Message-ID: Date: 19 Nov 90 19:44:23 GMT References: Sender: daemon@cgl.ucsf.edu Lines: 47 srp@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@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet