FTR RRL will not help on this case. There’s no difference between response with TC and response with REFUSED.
It would make a difference only if there was NOERROR response with data. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 16. 12. 2021, at 14:28, Reindl Harald <h.rei...@thelounge.net> wrote: > > > >> Am 16.12.21 um 14:22 schrieb Andrew P.: >> Sorry about forgetting to post the list. I hit Reply instead of Reply All. >> Annoying inconsistent list servers.... > > blame your mail-client for not support "reply-list" buttons and "reply-all" > is breaking this for me :-) > >> You don't understand what kind of blacklist I want; I want to blacklist the >> domain name being asked for, so I don't answer for it. I'm not looking to >> blacklist forged IP addresses of requestors (since we all know criminals >> don't use their own identities; they use the identities of innocent >> bystanders). >> Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am >> not a rootserver, and never will be. > > > AGAIN: you don't gain anything by not responding on a UDP protocol because > the client can't distinct no response and packet loss > > so you *increase* the load by retries on the client > > don't get me wrong but you need to understand the implications of what you > are doing - for DOS attacks "Response Rate Limiting" was invented and for > non-DOS requests there isn't any valid reason to take action > >> ________________________________________ >> From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Reindl >> Harald <h.rei...@thelounge.net> >> Sent: Thursday, December 16, 2021 8:14 AM >> To: bind-users@lists.isc.org >> Subject: Re: Millions of './ANY/IN' queries denied >>> Am 16.12.21 um 14:04 schrieb Andrew P.: >>> So you're claiming that legitimate resolvers would still be pointing at the >>> wrong IP address for a public DNS server after over 16 years? >> besides that i don't know why you are answering off-list nowhere did i >> say anything about 16 years >> but it can take time >> just because some IP is asking for a domain you don't host is for sure >> not a justification for automated blacklisting - that will happen >> regulary after domain-transfers for some time >>> And asking repeatedly and rapidly for the same illegal root domain name in >>> synchronized bursts of 10 queries supposedly from 10 different IP addresses? >> that's what "Response Rate Limiting" is for >>> I say that because I have held the particular static IPv4 address that my >>> nameserver is running on for that long, and I have never run a root >>> nameserver of any sort, or hosted domains for anyone but myself. >> fine, that's *your* case - we host 800 domains and all the time some get >> transferred to us and some get away >>> I agree with the concept of a blacklist >> i don't because the IP is in most cases FORGED >>> how do I set up one on my copy of bind so I can refuse to answer those >>> obvious DNS DDoS attacks? While still answering legitimate requests for the >>> domains I do hosts, that is. >> "Response Rate Limiting" >> again: the IP you mostly see is FORGED and the victim not the attacker >> and all you do is blacklisting the innocent victim which never did >> anything bad >> with automated blacklisting you expose yourself to a simple DOS attack - >> when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i >> take your domain offline for anybody on the planet using the google >> resolvers >> and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP >> resolvers for endusers - game over, you blacklisted the world >>> ________________________________________ >>> From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Reindl >>> Harald <h.rei...@thelounge.net> >>> Sent: Wednesday, December 15, 2021 8:44 AM >>> To: bind-users@lists.isc.org >>> Subject: Re: Millions of './ANY/IN' queries denied >>> >>> >>> >>> Am 15.12.21 um 14:33 schrieb Andrew P.: >>>> So why isn't there a way to tell BIND not to respond to queries for which >>>> it clearly is not authoritative (such as these attack vectors)? Since no >>>> legitimate resolver would be asking a non-authoritative server for >>>> information, why should his (or my) public BIND server respond to these >>>> even with an error message? >>> >>> because in case of UDP it would make things much worser >>> >>> how do the client smell that you didn't respond by purpose and distinct >>> it from packet loss leading to retries? >>> >>> ------------------ >>> >>> "Since no legitimate resolver would be asking a non authoritative server >>> for information" isn't true at all >>> >>> years ago we moved a server to a different location and all sorts of ISP >>> resolvers did respond with old IPs months later, the dumbest one even >>> played lottery responding 50% old and 50% new IP >>> >>> i found that out by random complaints because one domain had 60 count >>> subdomains and started to query all open rsolvers i was able to find >>> with script's - a tragedy >>> >>> that machine was sadly the primary NS for 800 domains and over the >>> months the old ip could have been ru-used for a new customer running a >>> nameserver for completly different domains >>> >>> ------------------ >>> >>> long story short: no sane service should supress replies completly >>> unless a explicit blacklist saying so is involved >>> >>>> ________________________________________ >>>> From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Ondřej >>>> Surý <ond...@isc.org> >>>> Sent: Wednesday, December 15, 2021 7:18 AM >>>> To: Danilo Godec >>>> Cc: bind-users@lists.isc.org >>>> Subject: Re: Millions of './ANY/IN' queries denied >>>> >>>>> Would I be doing a bad thing by using fail2ban to block these IPs? >>>> >>>> That’s the question that only you can answer. The IP addresses are >>>> not attacker’s but victim’s and you would be punishing those networks >>>> by blocking access from them to your network. >>>> >>>> Do you absolutely know that these IP addresses doesn’t need access >>>> to your DNS? If yes, then go ahead. > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
