Need help debugging negative caching

[Mark_Andrews at isc.org]

> Kevin Darcy <kcd at daimlerchrysler.com> wrote in message news:<akm0of$d0m$1 at isr
> v4.isc.org>...
> > joan.creus at lacaixa.es wrote:
> > 
> > > Kevin Darcy <kcd at daimlerchrysler.com> wrote in message news:<akjgp1$ep1l$
> 1 at isrv4.isc.org>...
> > > > joan.creus at lacaixa.es wrote:
> > > >
> > > > > Hi, everybody,
> > > > >
> > > > > I am running BIND 8.3, and I have a problem that involves negative
> > > > > caching. We start receiving queries to non-existent names. After a
> > > > > while, those names get created in a stub zone, but of course BIND
> > > > > keeps returning NXDOMAINs. After some time (which varies greatly,
> > > > > depending on the RR), BIND starts resolving those names. My goal is t
> o
> > > > > reduce this time, and make it predictable.
> > > >
> > > > Um, what do you mean by "get created in a stub zone"? One doesn't enter
> > > > resource records into stub zones.
> > >
> > > You are right. What I meant is that my server is a stub for a zone,
> > > which resides in another server. The RRs get added in that server.
> > > BTW, the RRs actually live in subzones within the stubbed zone.
> > >
> > > > Perhaps that is the problem?
> > > >
> > > > Or, perhaps you could look at the max-ncache-ttl option, which puts an
> > > > upper cap on the lifetime of negative caching entries.
> > > >
> > > > You are aware, hopefully, that any attempt to reduce negative caching
> > > > will result in higher consumption of network and processing resources. 
> It
> > > > may also cause your memory to thrash more, constantly adding and then
> > > > deleting negative cache entries.
> > >
> > > That might help, good hint. But it still doesn't explain the behaviour
> > > I am seeing. Perhaps the fact that the zone is divided into lots of
> > > subzones is causing some side effects. Which SOA prevails to decide
> > > the negative caching timeout? The SOA of the "parent" stubbed zone? Or
> > > the actual SOA of the subzone that owns the RR?
> > 
> > The zone containing the RR.
> > 
> > If the name is an "apex" name, i.e. the same as the name of the zone which 
> contains it, then
> > the SOA will have the same name.
> > 
> > > Perhaps I should change the stub to forward? I have full control over
> > > both servers, so that is not a problem.
> > 
> > Negative caching TTL is controlled by the last field of the SOA record. If 
> you want to speed up
> > expiration of negative cache entries, and you have control over the zones, 
> why don't you tune
> > that SOA field value to something lower?
> >
> >
> > - Kevin
> 
> The server that owns the zone is not RFC 2308-compliant, so it is
> still using that field as "default TTL". That will change, but in the
> meantime, we will have to play with the max-ncache-ttl parameter in
> BIND, and live with the side effects.
> 
> Thanks a lot for your help,
> 
>                                 Joan

	The fact that it is using it as the default TTL doesn't mean that
	it can't emit negative answers with the TTL you want.

	Just set the MINIMUM field to the TTL you want on the negative
	answers.  Use this TTL on the SOA.  Set explict TTLs on all the
	other records to the old MINIMUM value.

	Setting the MINIMUM field will allow slaves that talk RFC 2308 to
	do the right thing.  Setting the SOA TTL will get the non RFC 2308
	server to hand out the right TTL.  Setting explict TTLs on the other
	records will allow all servers to return the TTL you want for the
	forward records.

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