Re: RRL outcome on legitimate traffic...

2020-12-03 Thread Reindl Harald



Am 01.12.20 um 17:15 schrieb Karl Pielorz:
--On 1 December 2020 at 08:24:50 -0600 Lyle Giese  
wrote:



You need to look at the reply named sends when it trips and starts
limiting UDP traffic source from a given IP address.  It tells the
requestor to try again using TCP instead of UDP.

So if the requestor is a legit dns server, it will retry using TCP and
still get a valid answer.

Named does not blindly just drop traffic.


Hmmm, I thought it did for RRL limit hits? (i.e. that's the point - to 
stop sending responses)


irrelevant in context of TCP where forged source with the IP of the 
victim don't survive a handshake


the point of dns amplification over UDP is that the response of ANY 
queries is dramatically larger then the inbound package and no handshake 
is needed

___
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


Re: RRL outcome on legitimate traffic...

2020-12-01 Thread Lyle Giese

Probably best to ask Paul Vixie for confirmation.

I had implemented RRL when it was still an addon and that was what was 
documented back then.


On 12/1/20 10:15 AM, Karl Pielorz wrote:



--On 1 December 2020 at 08:24:50 -0600 Lyle Giese 
 wrote:



You need to look at the reply named sends when it trips and starts
limiting UDP traffic source from a given IP address.  It tells the
requestor to try again using TCP instead of UDP.

So if the requestor is a legit dns server, it will retry using TCP and
still get a valid answer.

Named does not blindly just drop traffic.


Hmmm, I thought it did for RRL limit hits? (i.e. that's the point - to 
stop sending responses).


Documentation for rate-limit seemed a bit patchy e.g. KB aa-00994 
references to "See ARM 6.2.15" - which doesn't exist. In fact a lot of 
the KB documents reference Bind 9.9 - and things have moved on.


But I can see it's better explained in the current ARM / Section 
4.2.14.19 now.


In fact, that entry also covers/says "Legitimate clients react to 
dropped or truncated response by retrying with UDP or with TCP 
respectively" - looks like it documents where these are in stats as 
well (RateDropped / QryDropped et'al) - so I think I'm good to go.


-Karl


___
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


Re: RRL outcome on legitimate traffic...

2020-12-01 Thread Karl Pielorz



--On 1 December 2020 at 08:24:50 -0600 Lyle Giese  
wrote:



You need to look at the reply named sends when it trips and starts
limiting UDP traffic source from a given IP address.  It tells the
requestor to try again using TCP instead of UDP.

So if the requestor is a legit dns server, it will retry using TCP and
still get a valid answer.

Named does not blindly just drop traffic.


Hmmm, I thought it did for RRL limit hits? (i.e. that's the point - to stop 
sending responses).


Documentation for rate-limit seemed a bit patchy e.g. KB aa-00994 
references to "See ARM 6.2.15" - which doesn't exist. In fact a lot of the 
KB documents reference Bind 9.9 - and things have moved on.


But I can see it's better explained in the current ARM / Section 4.2.14.19 
now.


In fact, that entry also covers/says "Legitimate clients react to dropped 
or truncated response by retrying with UDP or with TCP respectively" - 
looks like it documents where these are in stats as well (RateDropped / 
QryDropped et'al) - so I think I'm good to go.


-Karl

___
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


Re: RRL outcome on legitimate traffic...

2020-12-01 Thread Lyle Giese
You need to look at the reply named sends when it trips and starts 
limiting UDP traffic source from a given IP address.  It tells the 
requestor to try again using TCP instead of UDP.


So if the requestor is a legit dns server, it will retry using TCP and 
still get a valid answer.


Named does not blindly just drop traffic.

Lyle Giese

LCR Computer Services, Inc.

On 12/1/20 4:58 AM, Karl Pielorz wrote:


Hi all,

So there's been quite a thread - that originally started as "Bind 
stats - denied queries" - and morphed into a whole discussion on 
spoofed UDP, logging, RRL etc.


In my original post - I never said the original traffic was likely 
legitimate in anyway (just so we're clear - I didn't start that aspect 
of that thread).



So,

Obviously RRL is pretty much all you can do with this stuff - 
presumably, if someone throws a lot of queries that 'trip' the RRL - 
but, say spoofed from another ISP's actual DNS servers/network - the 
idea is that those IP's legitimate UDP queries will start getting 
dropped :( - but the other ISP's DNS will then, hopefully switch from 
UDP to TCP to get an answer?



Looking at the distribution of rubbish we're seeing - I'm suspecting 
some of the limits would have to be 'really low' to catch some of this 
stuff (i.e. some times we just see 5 queries from an IP, and then 
nothing for hours - even from within the same /24).


Obviously the server can weather a quite a bit of this, and you can't 
"block everything" (which is - in a circle, why I was asking 
originally about getting stats for it :)


Regards,

-Karl
___
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


RRL outcome on legitimate traffic...

2020-12-01 Thread Karl Pielorz



Hi all,

So there's been quite a thread - that originally started as "Bind stats - 
denied queries" - and morphed into a whole discussion on spoofed UDP, 
logging, RRL etc.


In my original post - I never said the original traffic was likely 
legitimate in anyway (just so we're clear - I didn't start that aspect of 
that thread).



So,

Obviously RRL is pretty much all you can do with this stuff - presumably, 
if someone throws a lot of queries that 'trip' the RRL - but, say spoofed 
from another ISP's actual DNS servers/network - the idea is that those IP's 
legitimate UDP queries will start getting dropped :( - but the other ISP's 
DNS will then, hopefully switch from UDP to TCP to get an answer?



Looking at the distribution of rubbish we're seeing - I'm suspecting some 
of the limits would have to be 'really low' to catch some of this stuff 
(i.e. some times we just see 5 queries from an IP, and then nothing for 
hours - even from within the same /24).


Obviously the server can weather a quite a bit of this, and you can't 
"block everything" (which is - in a circle, why I was asking originally 
about getting stats for it :)


Regards,

-Karl
___
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