[dnsdist] Suggestions for rules to block abusive traffic

[Frank @ kiwazo.be]

I've customers who are successful with an "abuse server" setup: traffic for domains which are attacked are moved to an "abuse" server which doesn't use a (traditional) database backend (most of them PDNS + LMDB). While some experiment with detection mechanisms, for most of them there's till a human involved in deciding if the domain should go the "abuse server".


For newer customers I setup a PDNS + LMDB instead of PDNS + DB. Now matter how hard you tune your database servers, you'll met get the performance of LMDB out of them. Obviously this has limits as well, and for those the only viable option is to move to an anycasted setup, where the DDoS load is automatically spread across a lot more servers.

Kind Regards,

Frank

Frank Louwers
PowerDNS Certified Consultant @ Kiwazo.be





> On 8 Jan 2024, at 17:28, Dan McCombs via dnsdist <dnsdist at mailman.powerdns.com> wrote:
> 
> Hi Klaus!
>  
>>  In our case we are affected as we use Pdns + DB backend as backend.
> 
> Yep, that's exactly our case as well - our legacy Pdns + mysql backends don't handle this very well. Longer term we intend to move away from that, but finding some improvements in the meantime for handling these floods would be helpful. I'll let you know if we come up with anything interesting!
> 
> -Dan
> 
> 
> 	
> 
> Dan McCombs
> Senior Engineer I - DNS
> dmccombs at digitalocean.com <mailto:dmccombs at digitalocean.com>
> 
> On Mon, Jan 8, 2024 at 8:31 AM Klaus Darilion <klaus.darilion at nic.at <mailto:klaus.darilion at nic.at>> wrote:
>> Hi Dan!
>> 
>>  
>> 
>> This is a known issue and we have not found a simple solution in dnsdist. And obviously it is only a problem if the backend is slow. In our case we are affected as we use Pdns + DB backend as backend.
>> 
>> Use a fast name server as additional backend (we used NSD) and dynamically provision targeted zones (and all subzones) on the faster backend and redirect the zone to the fast backend (dnsdist rule). Out detection is based on “dsc” statistics collector.
>> Use a fast nameserver instead of dnsdist + slow backend (we use Knot for customers that are constantly under attack)
>>  
>> 
>> These two methods helped us, but of course add additional operations work to implement and operate it.
>> 
>>  
>> 
>> If you find a simple dnsdist based solution to filter these random queries I would be interested too ;-)
>> 
>>  
>> 
>> Regards
>> 
>> Klaus
>> 
>>  
>> 
>> Von: dnsdist <dnsdist-bounces at mailman.powerdns.com <mailto:dnsdist-bounces at mailman.powerdns.com>> Im Auftrag von Dan McCombs via dnsdist
>> Gesendet: Freitag, 29. Dezember 2023 20:11
>> An: dnsdist at mailman.powerdns.com <mailto:dnsdist at mailman.powerdns.com>
>> Betreff: [dnsdist] Suggestions for rules to block abusive traffic
>> 
>>  
>> 
>> Hi all,
>> 
>> I'm wondering if anyone has suggestions of reasonable ways to handle this type of abusive traffic with dnsdist.
>> 
>> We've had on and off attacks recently targeting legitimate domains delegated to our authoritative service flooding queries for random subdomains of varying length and characters/words. i.e. 12345.example.com <http://12345.example.com/>, fred.example.com <http://fred.example.com/>, abc178371jd.example.com <http://abc178371jd.example.com/>, where example.com <http://example.com/> is a different domain we're authoritative for each attack.
>> 
>> The dnsdist nodes can handle the traffic, but breaking cache and going through to our backends is having more of an impact.
>> 
>>  
>> 
>> We have thousands of domains, so it doesn't seem reasonable to apply individual rate limits to them all, but if there is a straight forward way to do something like that I'd be happy to hear it. The source addresses are well known public resolvers that we shouldn't rate limit either.
>> 
>> I'm wondering if there's any way to detect and apply a rule dynamically to respond to queries for one of these domains without affecting the source IP address entirely, and not require us to manually add a rule for each domain as it occurs.
>> 
>> Any ideas would be appreciated.
>> 
>> Take care,
>> 
>> -Dan
>> 
>> 
>> 
>> 
>> 
>> Dan McCombs
>> 
>> Senior Engineer I - DNS
>> 
>> dmccombs at digitalocean.com <mailto:dmccombs at digitalocean.com>
>>  
>> 
> _______________________________________________
> dnsdist mailing list
> dnsdist at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/dnsdist/attachments/20240109/27b5f412/attachment.htm>