Weird named act!

[Mark Andrews]

> Holdsworth, Matthew wrote:
> 
> >Dear All,
> >
> >Can anyone shed any light on this one:
> >
> >We run BIND 9.2 on Solaris 8
> >
> >Every now and again we have to restart the named process on our DNS server.
> >Reason being, it stops resolving anything outside of its own zone.
> >
> >Eg.
> >Our resolv.conf file contains the line:
> >
> >search lond.dtv.cwctv.net lond.dtv.ntl dtv.cwctv.net dtv.ntl
> >ops.dtv.cwctv.net ops.dtv.ntl
> >
> >Now, when the problem occurs it will only resolv hosts from the first one in
> >the search list. It wont even forward queries for external hosts (web sites)
> >to our internet facing servers.
> >
> >After restarting the named process we can then resolv hosts from all the
> >above zones and web sites.
> >
> >I wondered if it could be the option 'datasize' being set too small. Ours is
> >just 20M.
> >
> BIND 9 shouldn't simply *stop* responding to queries when it hits 
> datasize. It should just slow down as it purges old cache entries and 
> has to fetch a higher proportion of new ones over the network for a 
> while. That being said, it might be the case that your nameserver slows 
> down so much maybe the resolver times out before the nameserver returns 
> the answer. You could probably get an idea of whether you're hitting a 
> datasize threshold by looking at the size of the named process with "ps 
> -flp {pid}". I would imagine named writes something to the log when it 
> reaches this threshold, so tweaking your logging options might give you 
> a confirmation also.
> 
> If I may get on my soapbox for a while, though, this is what happens 
> when you indulge searchlists too much. Probably much of your small cache 
> capacity is being squandered by bad searchlist guesses. Yes, that's 
> basically what the searchlist option does -- make the resolver *guess* 
> at what the domain is, by trial and error, one domain at a time, much as 
> you might hypothetically make the postal service guess at city, 
> state/province, zip code, or whatever, by omitting that information from 
> the recipient addresses of letters you send. Every "wrong" domain guess 
> leaves a negative cache entry in the nameserver, for some period of 
> time. Do you really think this is a reasonable use of caching, network 
> and processing resources? Sure, I've heard the "users don't want to type 
> fully-qualified names" argument a million times, but how many of your 
> queries come directly from user typing, really? If you're typical, the 
> vast majority come from automated processes, names read in from config 
> files, or bookmarks, or from URLs accessed via clicking on a hyperlink. 
> All of those categories of query sources could be converted over to 
> using fully-qualified names. Very few queries actually come from user 
> typing, so the "too much typing!" argument doesn't carry much weight 
> with me. To summarize: searchlists are evil, avoid them as much as possible.
> 
>                                                                          
>                                                             - Kevin

	datasize is *not* the correct option to control memory
	usage.  It really should only be used to *raise* the amount
	of memory available to the process.  Recovering from malloc
	failures is extremely hard to do properly.  You essentially
	have to stop everything, free dynamic memory and restart
	without having to allocate any memory until you start the
	restart process.

	named assumes that you have correctly sized datasize to allow
	for handle both the fixed and dynamic memory requirements.

	Fixed memory requirements include but are not limited to
	memory for authoritative zones, memory for clients and some
	general overhead.  Note when calculating the fixed requirements
	named sometimes has multiple copies of zones in memory at
	the same time.

	max-cache-size is the option to use to control the dynamic
	memory requirements.  When this limit is reached the cache
	will be randomly cleaned for datasets.  9.3 does a better
	job of this that 9.2 as adb's memory usage is now included.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org