restructuring/redesigning BIND (was Re: 9.2.5 db causes high cpu?)

[Mark Andrews]

> > yes, it is.  maybe you can help me understand the alternatives better?  when
> > we get a query for a zone we havn't loaded yet, should we answer SERVFAIL or
> > should we just silently drop the query?
> 
> If the server "knows" it will be loading that zone, it should silently drop the
>  
> query.  At the (considerable) risk of demonstrating my utter lack of specific 
> knowledge, SERVFAIL sounds like something that would result in an application 
> error, particularly for an application running on a poorly configured client 
> with only one nameserver configured.  While it is nice to say "well, such 
> clients deserve what they get" the practical (perhaps kludgy) side of me thinks
>  
> that would be iladvised.

	SERVFAIL is the generic error code when there is not a more
	specific error code.  "named" returns SERVFAIL if it attempted
	to load a zone but detected a error in the load process.
 
> Since zone loads are (should be?) considered infrequent transients, best to 
> "respond" in a manner similar to other transients - such as packet loss. 
> Unless and until there is a definition for the DNS equivalant of EAGAIN.
> just one opinion,
> 
> rick jones
	
	Below is a list of changes that have been made to reduce dead times.

	9.2 added incremental reloads of zones.
	9.3 added incremental writes of zones (slave and dynamic zones).
	9.2.4 and 9.3 have incremental destruction of internal databases,
	(this helps with some malloc implementations).

	9.2.5 and 9.3.1 fixed a hash bug which resulted in very long
	hash lists for rbl and deep in-addr zones and consequentally long
	removal times as the list is not doubly linked (it should only have
	a average depth of 3 not 1000s as we were seeing with the hash bug).

	Note these all deal with post startup issues.

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