named crashing with too many open files

[Jim Reid]

>>>>> "Ben" == Ben Stern <bstern at digex.net> writes:

    Ben> Upon further prodding, I've discovered that the problem is
    Ben> that named is trying ad infinitum to contact 3 particular
    Ben> servers, 2 of which are not reachable (behind a firewall or
    Ben> something) and one which is dns4.cp.msft.net - which may also
    Ben> be behind a firewall, but either way is refusing to answer us.

This doesn't mean a thing. It's quite common for some folk's name
servers to be unreachable. Your name server will not specially create
a unique socket (file descriptors) when sending UDP queries to another
server. It uses one socket for all outbound queries. This means file
descriptors should get used up talking to those unreachable
servers. However named could use a file descriptor for each TCP
connection it tries to initiate to those dead/unreachable servers. But
those descriptors would be recycled after a few minutes when the TCP
connections fail and their PCBs get torn down. And anyway it would
take an awful lot of zone transfers requests or truncated replies from
those servers - TCP traffic - to account for file descriptor
exhaustion.

    Ben> What can I do to convince named not to spend all of it's open
    Ben> files on these hosts, but instead do something useful, like
    Ben> answer queries?

How do you *know* it's wasting open files on these dead hosts? Where's
the proof? If this really is the problem - I doubt it - then you can
use server{} statements to mark them as bogus. And if their IP
addresses are listed in zone{} statements, you could remove them.
What did lsof have to say about the descriptors named was using?
Could you have lots of inbound TCP connections to the name server, ie
lots of incoming zone transfer requests?