Bind9(9.3.2p1) "out of memory"

[Adam Young]

Hi Mark,

> > It shouldn't continue searching after a successful lookup.  You need to
> > investigate the client, this isn't a problem with the server.
> 
> 	The client is most probably AAAA queries in series rather than
> 	in parallel with A queries.  The resolver doesn't stop searching
> 	on NODATA responses.
> 
> 	e.g.
> 		look for Isc.org, Isc.org.localnet and
> 		Isc.org.mountaincable.net A records stopping on first
> 		match then look for Isc.org, Isc.org.localnet and
> 		Isc.org.mountaincable.net AAAA records stopping on first
>                 match
> 
> 		rather than
> 
> 		looking for Isc.org A and AAAA records and stopping
> 		on either matching then if no match Isc.org.localnet
> 		A and AAAA records and stopping on either matching
> 		then if no match Isc.org.mountaincable.net A and
> 		AAAA records and stopping on either matching.
> 
> 	I can only presume not stopping on NODATA was to handle
> 	looking for A records in the presence of wildcard MX records
> 	in pre RFC 1535 aware resolvers which walked the search
> 	list before multi-label names were tried as is.  Most of
> 	the early use of wildcards was to handle email.
>

I used isc.org as an example, I suppose I shouldn't have.  It isn't a domain
that exhibits the same queries.

I will give you a true example:

client 172.16.51.3#52737: query: ldapx.localnet IN AAAA +
client 172.16.51.3#52737: query: ldapx.localnet.localnet IN AAAA +
client 172.16.51.3#52737: query: ldapx.localnet.mountaincable.net IN AAAA +
client 172.16.51.3#52737: query: ldapx.localnet IN A +

So it sounds like it is doing what you mentioned, and I'm assuming this is
expected.

I'm just wondering if this is what may be causing us to have a really large
cache (7days ~ 3G of memory used by 'named' process).

Thanks again, you guys have been very helpful with the problems I have been
having.

-
Adam Young
Systems Support Technologist
Mountain Cablevision Ltd.
(905)667-7436