<div dir="ltr"><div>This is probably from 1 source only but spoofing the source address, one pattern of attacking DNSs that was common some years ago (2013/2014 hits my memory more on this) was to fake query origin making the DNS server thing there was tons of different IPs querying the server and in reality was only one IP trying to cause a Reflection Attack or DoS.<br></div><div><br></div><div>There's not many options to reduce query load in Auth DNS in this case that works very well against subdomains, from what I recall iptables / netfilter can use hexadecimal strings to filter out those queries before they do the real query but this is expensive in terms of CPU (still needs to test it against your scenario). Other than that you can put a DNS cache in front of the authoritative to hold off those aggressive queries and give it a nice slab of RAM. <br></div><div><br></div><div>Best regards,</div><div>Filipe<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 10:36 AM Brian Candler <<a href="mailto:b.candler@pobox.com">b.candler@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 29/04/2019 22:14, Klaus Darilion wrote:<br>
> Can you give an example how those dynblockrules can be used to filter <br>
> above "attack"? The main problem with rate-limiting NXDOMAIN is, that <br>
> you need to ask the authoritative to get a response and check if it is <br>
> NXDOMAIN. Then, dropping the response is actually no help as the <br>
> authoritative still gets the query load.<br>
<br>
In the normal case, suppressing responses may be a good thing to do, if <br>
the actual problem is that the DNS responses are part of a DoS attack <br>
(i.e. the DNS queries came in with spoofed source addresses).  The <br>
responses cause your IP reputation to suffer - and burn outbound bandwidth.<br>
<br>
><br>
> Also if the source IP is random, you can not block a source-IP after <br>
> too many NXDOMAINs.<br>
<br>
That is true, but:<br>
<br>
1. In that case, how would you propose dealing with random source IPs?  <br>
That is: how could you tell the difference between a valid query which <br>
demands an NXDOMAIN response, mixed in with the "attacking" queries?<br>
<br>
2. Why would someone send you lots of queries with *random* source IPs?  <br>
Have you analyzed them, are you sure they're random? An attacker would <br>
normally put a victim's IP in the source, or a small set of victim <br>
source IPs.  Sending truly random source IPs wouldn't achieve very much, <br>
apart from wasting your resources (and theirs).<br>
<br>
Regards,<br>
<br>
Brian.<br>
<br>
_______________________________________________<br>
Pdns-users mailing list<br>
<a href="mailto:Pdns-users@mailman.powerdns.com" target="_blank">Pdns-users@mailman.powerdns.com</a><br>
<a href="https://mailman.powerdns.com/mailman/listinfo/pdns-users" rel="noreferrer" target="_blank">https://mailman.powerdns.com/mailman/listinfo/pdns-users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">[ ]'s<br><br>Filipe Cifali Stangler<br></div>