Strange behavior of named

[Barry D. Hassler]

First of all, lets get the versions out of the way: I am  running
BIND 4.8 on Pyramid 9010's (98Xe's in reality). I have two ident-
ically configured systems operating as redundant network gateways
between  MILNET  and 8 local networks, and also acting as primary
domain servers for the WPAFB.AF.MIL domain.  These two hosts  are
NAP1.ARPA (26.4.0.176) and NAP2.ARPA (26.18.0.124).

For the past two days, I have been having very regular crashes of
named on one of these systems (NAP1.ARPA, NAP2 remains operation-
al just fine).  The curious thing is, is that it  crashes  ALWAYS
after  receiving  and updating the database with information from
NS.NASA.GOV. Previous to yesterday, I had NS.NASA.GOV  listed  in
my cache as a server for the root domain. After seeing this error
and examining the named.run file, I didn't see NS.NASA.GOV listed
in  the  information  being returned from SRI-NIC.ARPA concerning
the root servers, so I took it out of my cache. I restarted named
and  everything ran fine and dandy until today. This morning when
I checked, I had again crashed. After watching the named.run file
again,  I  noticed that now I was receiving NS.NASA.GOV as a root
server from the NIC, so I added it again to my cache and  started
things up, but to no avail.

Anyway, I am unable to keep named running on  NAP1.ARPA  at  all.
Since  the  named.run  file is so large, I haven't included it in
this message, but if anyone can help me on this, and needs to see
it,  it  is  available  via  anonymous  FTP  on  ASD.WPAFB.AF.MIL
(129.48.1.13) in pub/nap1.named.run.

I'd appreciate any ideas any might have.

Relatedly, about three weeks ago, there  were  messages  sent  to
INFO-PYRAMID concerning the fact that pyramid was distributing an
OLD version of BIND, and that it was causing  several  people  to
have  difficulties in receiving information from the WPAFB.AF.MIL
domain. I have since upgraded to 4.8, and with the  exception  of
this problem, it has been running fine on the Pyramids.

Many thanks in advance,

Barry D. Hassler
Control Data Corporation
Integration Services Division