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
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
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
-bounces+jason.brown=kcom@lists.isc.org] On Behalf Of
Peter Andreev
Sent: 28 February 2014 09:36
To: Dmitry Rybin
Cc: BIND Users Mailing List
Subject: Re: Bind vs flood
Well, at first glance it looks like malicious activity, so the best action is
to call all users, suspected in sending
: Bind vs flood
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
To: bind-users@lists.isc.org
Subject: Re: Bind vs flood
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
: Re: Bind vs flood
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 on your resolver. This should supress
LAB'd this and am
always happy to be wrong as it means I have learnt something new! :)
From: Chris Buxton [cli...@buxtonfamily.us]
Sent: 28 February 2014 17:57
To: Jason Brown
Cc: Ivo; BIND Users
Subject: Re: Bind vs flood
On Feb 28, 2014, at 2:12 AM, Jason Brown
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
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,
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.
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.
--
Hi Dmitry,
We observed that similar requests are landing on our cache resolver
mostly from various home routers running dns server as open resolver and
that also masquerades the original request source.
We have a collection of ~60 domains involved and most of them are
related to China. The
I guess I am missing why anyone on the internet should be able to open
queries against your caching resolver.
Why would in bound queries be allowed to servers that are for your people
to get out?
On Feb 27, 2014 10:13 AM, Ivo i...@nic.lv wrote:
Hi Dmitry,
We observed that similar requests
Doesn't this look like a DDOS attack on the spoofed origin of the queries?
On 27/02/14 16:18, Ben Croswell wrote:
I guess I am missing why anyone on the internet should be able to open
queries against your caching resolver.
Why would in bound queries be allowed to servers that are for your
Ben,
No, our server is not an open resolver, we have a large user community
and the problem is that users install their own wifi box like Zyxel or
similar which may have open resolver by default.
Ivo
On 2/27/14 5:18 PM, Ben Croswell wrote:
I guess I am missing why anyone on the internet
Ah I see you are in provider situation. Shows my assumption you were in an
enclosed enterprise environment.
On Feb 27, 2014 10:57 AM, Ivo i...@nic.lv wrote:
Ben,
No, our server is not an open resolver, we have a large user community
and the problem is that users install their own wifi box
Hi Dmitry,
If your problem is a lot of strange queries, then there is two ways:
1. You operate an open resolver. If you can - restrict it to a limited
scope of clients, otherwise the only way you can lower number of incoming
queries is DPI;
2. You operate a non-open resolver. Then you can find
18 matches
Mail list logo
