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.rei...@thelounge.net> wrote: > Am 25.06.2018 um 17:37 schrieb Barry Margolin: > > In article <mailman.82.1529939079.803.bind-us...@lists.isc.org>, > > Paul Kosinski <b...@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 > > _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users