Re: Bind vs flood

2014-02-28 Thread Dmitry Rybin
On 27.02.2014 09:59, Dmitry Rybin wrote: Bind answers with Server failure. On high load (4 qps) all normal client can get Servfail on good query. Or query can execute more 2-3 second. I have an a mistake, 4'000 QPS. ___ Please visit

Re: Bind vs flood

2014-02-28 Thread Peter Andreev
Well, at first glance it looks like malicious activity, so the best action is to call all users, suspected in sending such requests, and warn them. The fast and very (very-very-very) dirty solution is to set up zone 84822258.com http://niqcs.www.84822258.com on your resolver. This should supress

Re: Bind vs flood

2014-02-28 Thread Peter Andreev
However, if you choose the second action, then your tech support should be ready. 2014-02-28 13:36 GMT+04:00 Peter Andreev andreev.pe...@gmail.com: Well, at first glance it looks like malicious activity, so the best action is to call all users, suspected in sending such requests, and warn

RE: Bind vs flood

2014-02-28 Thread Jason Brown
Isn't this where RPZ comes in? Using RPZ means it is quicker and easier to null amplification, also easier to remove if you do all this with nsupdate, you can also create a webpage for TS to query any fault against. From: bind-users-bounces+jason.brown=kcom@lists.isc.org

Re: Bind vs flood

2014-02-28 Thread Ivo
RPZ cannot rewrite servfail, it is designed to replace a valid response. On 2/28/14 11:42 AM, Jason Brown wrote: Isn't this where RPZ comes in? Using RPZ means it is quicker and easier to null amplification, also easier to remove if you do all this with nsupdate, you can also create a webpage

RE: Bind vs flood

2014-02-28 Thread Jason Brown
But, it will respond with a valid response (your choice) and therefore not create a servfail due to trying.. that's my point. From: bind-users-bounces+jason.brown=kcom@lists.isc.org [mailto:bind-users-bounces+jason.brown=kcom@lists.isc.org] On Behalf Of Ivo Sent: 28 February 2014 10:10

which Name sever is selected?

2014-02-28 Thread houguanghua
If there is a list of NS records, the local name server uses the RTT (round trip time) algorithm to find the fatest, and queries that server. But I found it's not right. In the testing, the local name server doesn't query the fastest authority name server. Some one tells me that if the local

Re: which Name sever is selected?

2014-02-28 Thread Georg Kahest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/28/2014 04:14 PM, houguanghua wrote: If there is a list of NS records, the local name server uses the RTT (round trip time) algorithm to find the fatest, and queries that server. But I found it's not right. In the testing, the local name

Re: which Name sever is selected?

2014-02-28 Thread Warren Kumari
On Fri, Feb 28, 2014 at 2:55 PM, Georg Kahest georg.kah...@internet.ee wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/28/2014 04:14 PM, houguanghua wrote: If there is a list of NS records, the local name server uses the RTT (round trip time) algorithm to find the fatest, and

Re: which Name sever is selected?

2014-02-28 Thread Barry Margolin
In article mailman.2368.1393596895.20661.bind-us...@lists.isc.org, houguanghua houguang...@hotmail.com wrote: If there is a list of NS records, the local name server uses the RTT (round trip time) algorithm to find the fatest, and queries that server. But I found it's not right. In the

Re: which Name sever is selected?

2014-02-28 Thread Ben Croswell
RTT banding was removed in early versions of 9.8 due to the performance hit being larger than any security benefit. So it would depend what version of bind is being used in this case. https://www.isc.org/blogs/rtt-banding-removal-from-bind-9/ It is important to note that all ns records will take

Re: Bind vs flood

2014-02-28 Thread Chris Buxton
On Feb 28, 2014, at 2:12 AM, Jason Brown jason.br...@kcom.com wrote: But, it will respond with a valid response (your choice) and therefore not create a servfail due to trying.. that’s my point. Nope. RPZ only alters responses as they're on their way back to the requestor. The query is still

RE: Bind vs flood

2014-02-28 Thread Jason Brown
Three out of the four policy triggers are based on target data and that is applied after recursion (like you say), the fourth policy trigger (QNAME) as I understand it applies to the requested domain name, the method that I refer to is using the QNAME policy trigger. I must admit I have never

Re: Bind vs flood

2014-02-28 Thread Cathy Almond
On 28/02/2014 17:57, Chris Buxton wrote: On Feb 28, 2014, at 2:12 AM, Jason Brown jason.br...@kcom.com mailto:jason.br...@kcom.com wrote: But, it will respond with a valid response (your choice) and therefore not create a servfail due to trying.. that’s my point. ** Nope. RPZ only

RE: Bind vs flood

2014-02-28 Thread Phil Mayers
I think Chris is right here. IIRC even qname policies perform an upstream query - we've seen this reflected in response times. I don't know what it does for servfail but it would certainly be reasonable to pass them unchanged. Remember rpz is deliberately limited. -- Sent from my phone with,

Re: Bind vs flood

2014-02-28 Thread Evan Hunt
On Fri, Feb 28, 2014 at 09:38:23PM +, Phil Mayers wrote: I think Chris is right here. IIRC even qname policies perform an upstream query - we've seen this reflected in response times. I don't know what it does for servfail but it would certainly be reasonable to pass them unchanged.

Re: Bind vs flood

2014-02-28 Thread Phil Mayers
As Cathy mentioned, it's possible to bypass the recursion in RPZ now. The feature is in the rpz2 patches, which are included with BIND 9.10 and are also built into some packaged versions of BIND. So I just saw. I hadn't spotted that this was in the rpz2 patches; potentially quite useful. --