Need help debugging negative caching

[Kevin Darcy]

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 to
> > > 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