Stopping name server abuse

Paul Kosinski bind at iment.com
Mon Jun 25 20:01:13 UTC 2018


Somebody who has irresponsibly (and apparently wantonly, given his
refusal to fix it) delegated his domain(s) to your DNS server is
essentially causing a (modest bandwidth) distributed denial of service
attack on your server. I don't think that the "responsible" thing to do
is to sit there and suffer from a significantly increased load.

What should be done is to get the domain(s) revoked if the owner
continues to refuse to remedy the problem: it is *he*, not you, who is
being irresponsible. And if the queries are coming via an innocent
ISP's resolver, then they are inadvertently assisting in the attack,
and should be contacted and asked to help in the remediation. (Note
that *their* resources, as well as yours, are being wasted.)


On Mon, 25 Jun 2018 17:47:23 +0200
Reindl Harald <h.reindl at thelounge.net> wrote:

> Am 25.06.2018 um 17:37 schrieb Barry Margolin:
> > In article <mailman.82.1529939079.803.bind-users at lists.isc.org>,
> >  Paul Kosinski <bind at iment.com> wrote:
> > 
> >> How does *not* responding to a UDP query take longer for the
> >> *server* than responding to UDP a query? Both responding and
> >> (deliberately) not responding require identifying the query, but
> >> not responding bypasses the time the server would need to
> >> construct the response, plus time spent in the network stack. (I'm
> >> assuming we don't care about client side "expense".)
> > 
> > If there's no response, the client retries several times. It will
> > try all the servers that the zone is delegated to, so you'll put
> > more load on multiple servers.
> > 
> > NXDOMAIN responses are cached, it's one hit and then nothing for a
> > while
> 
> and additionally "I'm assuming we don't care about client side
> "expense" is nonsense because the client in question is typically a
> *innocent* ISP resolver or something like 8.8.8.8 and the attitude "i
> don't care about them" is irresponsible because as sysadmin you are
> expected to think what your actions mean for the whole ecosystem
> 
> 


More information about the bind-users mailing list