Stopping name server abuse

[Browne, Stuart]

If the incoming query has already been parsed and it BIND instance now knows it doesn't need to respond, it's already done all the work, so there's no point not sending the response. To introduce something before the BIND instance in userspace, then for every legitimate query you are double-processing; more wasted resources.

In either case, by 'not responding', you're tying up even more resources (open sockets or other connection tracking mechanisms if you haven't disabled them) until the connections all time out.

If you're filtering on an upstream device that can do that level of analysis without hurting your network, then maybe, but once again, you're double-processing every legitimate query; you're only moving the cost to a different device.

It's best to respond nicely and move on.

Unless the DNS server is massively under-resourced or the query load is in the many-thousands-per-second range, there shouldn't be that much of an issue with the server coping with the load; but from what I can tell on this thread, it's more about "The customer is no longer paying so I want to stop spending money or resources for them".

Stuart

> -----Original Message-----
> From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of
> Paul Kosinski
> Sent: Monday, 25 June 2018 1:40 PM
> To: bind-users at lists.isc.org
> Subject: Re: Stopping name server abuse
> 
> Is it possible to get BIND not to respond at all, thereby causing
> a timeout on the query? That would perhaps reduce load more than
> NXDOMAIN or deleting the sone(s) would.
> 
> 
> On Mon, 25 Jun 2018 00:03:09 +0200
> jonny at hasig.de wrote:
> 
> > yes, but it minimizes the use of resources because the only answer is
> > nxdomain. j.
> >
> > Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> > > In article <mailman.70.1529876093.803.bind-users at lists.isc.org>,
> > >   jonny at hasig.de wrote:
> > >
> > >> hi,
> > >> why dont you just delete the zones?
> > >
> > > That won't stop the queries from coming to the server.