BIND9 negative cache after timeout.

[Jan Gyselinck]

On Tue, Aug 05, 2003 at 02:49:40PM +0100, Simon Waters wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jan Gyselinck wrote:
> > On Thu, Jul 03, 2003 at 09:47:21AM +1000, Mark_Andrews at isc.org wrote:
> >
> >>	And it is also a easy one to prevent.  Don't have a wide
> >>	open caching server.  Apply anti-spoofing filters at the
> >>	IP level.
> >
> >
> > It helps somewhat, but that's not preventing the problem.
> > You don't need a wide open resolver to get this.  Enough
> > customers that use the resolver are enough to hit this often
> > enough too.
> 
> Mark is addressing the question of deliberate attack. Ultimately you can
> make any service unusuable if it doesn't restrict your clients (or
> others) ability to use it.

And I'm arguing that you don't need a deliberate attack to get this
kind of problems.  Restricting who can use your nameserver isn't
necessairily enough to solve those problems.  
 
> Have you tried upping the "recursive client" limit to a value more
> suitable for your number of clients?

Yes, but that means you'll loose lots of memory on that too.  And it
still doesn't solve the problem, it does not scale.  You know, some
clients like to use the available resolvers to process their 
I-don't-know-what logs and get all IP's in there resolved to hostnames.
Ofcourse there are ways to do that that don't stress ISP resolvers,
but ofcourse you'll always find clueless people on that subject.
So it's a fact of life you will get repetitive queries, and sometimes
a lot more than you would have wished.  It's not that rare to encounter
multiple non-resolving IP's in such logs.  And also, because not all
such scripts do caching, you can be sure if there's 5000 times in a short
time a certain unresolvable IP in there, you lost 5000 "recursive client"
slots on one customer (as it takes time before bind realizes that
the authorative nameservers don't reply) and in reality it's probably
even worse, as stub resolvers tend to retry when an answer doesn't
come back in time.  

> > there are lots of stubresolvers out there that keep
> > querying for the same name if it doesn't resolve (ServFail and
> > friends).
>
> If you can identify it log a bug report for the application re: RFC1123.

That's a solution.  Another solution would be to have the customer run
his own caching resolver.  All very nice, but a) you can't fix all
defective applications and b) you can't fix all your customers.  It
would be nice if we could fix c) our caching resolvers to handle this
gracefully.


Jan Gyselinck