Re: Bind vs flood

[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.
-- 
Sent from my phone with, please excuse brevity and typos
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[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. Remember rpz is deliberately limited.

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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Bind vs flood

[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, please excuse brevity and typos___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[Cathy Almond]

On 28/02/2014 17:57, Chris Buxton wrote:
> On Feb 28, 2014, at 2:12 AM, Jason Brown  > 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 resolved normally first. It does not
> short-circuit recursion.
> 
> Chris Buxton

FYI there's a new option being introduced in 9.10 that allows you to
apply RPZ rules ahead of recursion (you still need to know the names
that you want to rewrite though):

"qname-wait-recurse no;"

Cathy
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Bind vs flood

[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 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 
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 alters responses as they're on their way back to the requestor. 
The query is still resolved normally first. It does not short-circuit recursion.

Chris Buxton




From: 
bind-users-bounces+jason.brown=kcom@lists.isc.org<mailto: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
To: bind-users@lists.isc.org<mailto: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 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<mailto:bind-users-bounces+jason.brown=kcom@lists.isc.org>
 [mailto:bind-users-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 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 outgoing queries and thus minimize resolving time.

2014-02-28 12:06 GMT+04:00 Dmitry Rybin 
mailto:kirg...@corbina.net>>:
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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users



--
Is there any problem Exterminatus cannot solve? I have not found one yet.




This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. 
If you are not the intended recipient, any use, disclosure, copying or 
forwarding of this email and/or its attachments is unauthorised. If you have 
received this email in error please notify the sender by email and delete this 
message and any attachments immediately. Nothing in this email shall bind the 
Company or any of its subsidiaries or businesses in any contract or obligation, 
unless we have specifically agreed to be bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, 
company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
HU1 3RE.

118288 - KCOM Group UK Directory Enquiries. Calls will cost no more than £2.58 
connection + £1.79p per minute following the first 60 seconds, including VAT 
from a KC or BT landline. Call charges from mobiles and other networks may 
vary. If you are calling from a mobile you will now receive your requested 
number via text message. You will not be charged for the text message.





___

Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list



bind-users mailing list

bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>

https://lists.isc.org/mailman/listinfo/bind-users






This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. 
If you are not the intended recipient, any use, disclosure, copying or 
forwarding of this email and/or its attachments is unauthorised. If you have 
received this email in error please notify the sender by email and delete this 
message and any attachments immediately. Nothing in this email shall bind the 
Company or any of its subsidiaries or busi

Re: Bind vs flood

[Chris Buxton]

On Feb 28, 2014, at 2:12 AM, Jason Brown  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 resolved normally first. It does not short-circuit recursion.

Chris Buxton




> 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
> 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 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 
> [mailto:bind-users-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 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 outgoing queries and thus 
> minimize resolving time.
>  
> 2014-02-28 12:06 GMT+04:00 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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> -- 
> Is there any problem Exterminatus cannot solve? I have not found one yet.
> 
> 
> 
> 
> 
> This email has been scanned for all viruses.
> 
> Please consider the environment before printing this email.
> 
> The content of this email and any attachment is private and may be 
> privileged. If you are not the intended recipient, any use, disclosure, 
> copying or forwarding of this email and/or its attachments is unauthorised. 
> If you have received this email in error please notify the sender by email 
> and delete this message and any attachments immediately. Nothing in this 
> email shall bind the Company or any of its subsidiaries or businesses in any 
> contract or obligation, unless we have specifically agreed to be bound.
> 
> KCOM Group PLC is a public limited company incorporated in England and Wales, 
> company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
> HU1 3RE.
> 
> 118288 - KCOM Group UK Directory Enquiries. Calls will cost no more than 
> £2.58 connection + £1.79p per minute following the first 60 seconds, 
> including VAT from a KC or BT landline. Call charges from mobiles and other 
> networks may vary. If you are calling from a mobile you will now receive your 
> requested number via text message. You will not be charged for the text 
> message.
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>  
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>  
> 
> 
> 
> 
> This email has been scanned for all viruses.
> 
> Please consider the environment before printing this email.
> 
> The content of this email and any attachment is private and may be 
> privileged. If you are not the intended recipient, any use, disclosure, 
> copying or forwarding of this email and/or its attachments is unauthorised. 
> If you have received this email in error please notify the sender by email 
> and delete this message and any attachments immediately. Nothing in this 
> email shall bind the Company or any of its subsidiaries or businesses in any 
> contract or obligation, unless we have specifically agreed to be bound.
> 
> KCOM Group PLC is a public limited company incorporated in England and Wales, 
> company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
> HU1 3RE.
> 
> 118288 - KCOM Group UK Directory Enquiries. Calls will cost no more than 
> £2.58 connection + £1.79p p

RE: Bind vs flood

[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
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 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<mailto:bind-users-bounces+jason.brown=kcom@lists.isc.org>
 [mailto:bind-users-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 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 outgoing queries and thus minimize resolving time.

2014-02-28 12:06 GMT+04:00 Dmitry Rybin 
mailto:kirg...@corbina.net>>:
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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users



--
Is there any problem Exterminatus cannot solve? I have not found one yet.




This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. 
If you are not the intended recipient, any use, disclosure, copying or 
forwarding of this email and/or its attachments is unauthorised. If you have 
received this email in error please notify the sender by email and delete this 
message and any attachments immediately. Nothing in this email shall bind the 
Company or any of its subsidiaries or businesses in any contract or obligation, 
unless we have specifically agreed to be bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, 
company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
HU1 3RE.

118288 - KCOM Group UK Directory Enquiries. Calls will cost no more than £2.58 
connection + £1.79p per minute following the first 60 seconds, including VAT 
from a KC or BT landline. Call charges from mobiles and other networks may 
vary. If you are calling from a mobile you will now receive your requested 
number via text message. You will not be charged for the text message.





___

Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list



bind-users mailing list

bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>

https://lists.isc.org/mailman/listinfo/bind-users





This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. 
If you are not the intended recipient, any use, disclosure, copying or 
forwarding of this email and/or its attachments is unauthorised. If you have 
received this email in error please notify the sender by email and delete this 
message and any attachments immediately. Nothing in this email shall bind the 
Company or any of its subsidiaries or businesses in any contract or obligation, 
unless we have specifically agreed to be bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, 
company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
HU1 3RE.

118288 - KCOM Group UK Directory Enquiries. Calls will cost no more than £2.58 
connection + £1.79p per minute following the first 60 seconds, including VAT 
from a KC or BT landline. Call charges from mobiles and other networks may 
vary. If you are calling from a mobile you will now receive your requested 
number via text message. You will not be charged for the text message.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[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 for TS to query any fault
> against.
>
>  
>
> *From:*bind-users-bounces+jason.brown=kcom@lists.isc.org
> [mailto:bind-users-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 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 outgoing queries and thus minimize resolving time.
>
>  
>
> 2014-02-28 12:06 GMT+04:00 Dmitry Rybin  <mailto:kirg...@corbina.net>>:
>
> 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 https://lists.isc.org/mailman/listinfo/bind-users
> <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
>
> -- 
> Is there any problem Exterminatus cannot solve? I have not found one yet.
>
>
>
>
>
> This email has been scanned for all viruses.
>
> Please consider the environment before printing this email.
>
> The content of this email and any attachment is private and may be
> privileged. If you are not the intended recipient, any use,
> disclosure, copying or forwarding of this email and/or its attachments
> is unauthorised. If you have received this email in error please
> notify the sender by email and delete this message and any attachments
> immediately. Nothing in this email shall bind the Company or any of
> its subsidiaries or businesses in any contract or obligation, unless
> we have specifically agreed to be bound.
>
> KCOM Group PLC is a public limited company incorporated in England and
> Wales, company number 02150618 and whose registered office is at 37
> Carr Lane, Hull, HU1 3RE.
>
> 118288 - KCOM Group UK Directory Enquiries. Calls will cost no more
> than £2.58 connection + £1.79p per minute following the first 60
> seconds, including VAT from a KC or BT landline. Call charges from
> mobiles and other networks may vary. If you are calling from a mobile
> you will now receive your requested number via text message. You will
> not be charged for the text message.
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Bind vs flood

[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 
[mailto:bind-users-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 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 outgoing queries and thus minimize resolving time.

2014-02-28 12:06 GMT+04:00 Dmitry Rybin 
mailto:kirg...@corbina.net>>:
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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users



--
Is there any problem Exterminatus cannot solve? I have not found one yet.




This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. 
If you are not the intended recipient, any use, disclosure, copying or 
forwarding of this email and/or its attachments is unauthorised. If you have 
received this email in error please notify the sender by email and delete this 
message and any attachments immediately. Nothing in this email shall bind the 
Company or any of its subsidiaries or businesses in any contract or obligation, 
unless we have specifically agreed to be bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, 
company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
HU1 3RE.

118288 - KCOM Group UK Directory Enquiries. Calls will cost no more than ?2.58 
connection + ?1.79p per minute following the first 60 seconds, including VAT 
from a KC or BT landline. Call charges from mobiles and other networks may 
vary. If you are calling from a mobile you will now receive your requested 
number via text message. You will not be charged for the text message.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[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 :

> 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 outgoing queries and thus minimize resolving time.
>
>
> 2014-02-28 12:06 GMT+04:00 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 https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
>
> --
> Is there any problem Exterminatus cannot solve? I have not found one yet.
>
>


-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[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  on your resolver. This should
supress outgoing queries and thus minimize resolving time.


2014-02-28 12:06 GMT+04:00 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 https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[Ben Croswell]

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"  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 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 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"  wrote:
>
>>  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 problem is that attacker selects few domains and generates
>> queries with random hostnames which therefore are not in the cache and
>> server has to perform recursion for each query. So each query will consume
>> one udp or tcp socket for at least 10 seconds because remote DNS server is
>> responding slowly or is down and based on a query volume it can effectively
>> overload the cache server.
>>
>> Initially we thought we could fix it with " resolver-query-timeout", but
>> after bind code analysis it seems that everything less that 10 seconds
>> would be ignored, it would be great to mention this in the documentation.
>> So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c and
>> recompile named, but  it would be nice to understand why 10 seconds as
>> minimum value were selected in the first place, see /lib/dns/resolver.c
>>
>> #define MAX_SINGLE_QUERY_TIMEOUT 9U
>> #define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U)
>>
>> snip
>>
>> void
>> dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int seconds) {
>> REQUIRE(VALID_RESOLVER(resolver));
>> if (seconds == 0)
>> seconds = DEFAULT_QUERY_TIMEOUT;
>> if (seconds > MAXIMUM_QUERY_TIMEOUT)
>> seconds = MAXIMUM_QUERY_TIMEOUT;
>> if (seconds < MINIMUM_QUERY_TIMEOUT)
>> seconds =  MINIMUM_QUERY_TIMEOUT;
>> resolver->query_timeout = seconds;
>> }
>>
>> We also tried to create local dummy zones for all these domains but since
>> domains change frequently we started to block most active open resolvers
>> and coordinate with local CERT.
>>
>> It would be nice to have some kind of rate limits for query volume of
>> different hosts inside a single zone.
>>
>> Best regards,
>>
>> Ivo
>>
>>
>> On 2/27/14 7:59 AM, Dmitry Rybin wrote:
>>
>> Over 2 weeks ago begins flood. A lot of queries:
>>
>> niqcs.www.84822258.com
>> vbhea.www.84822258.com
>> abpqeftuijklm.www.84822258.com
>> adcbefmzidmx.www.84822258.com
>> and many others.
>>
>> 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.
>>
>> Recursion clients via "rnds status" 300-500.
>>
>> I can try to use rate limit:
>> rate-limit {
>> nxdomains-per-second 10;
>> errors-per-second 10;
>> nodata-per-second 10;
>> };
>> I do not see an any improvement.
>>
>> Found one exit in this situation, add flood zones local.
>>
>> What can we do in this situation?
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> 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
>>
>> 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
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[Ivo]

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 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" mailto:i...@nic.lv>> wrote:
>
> 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 problem is that attacker selects few domains
> and generates queries with random hostnames which therefore are
> not in the cache and server has to perform recursion for each
> query. So each query will consume one udp or tcp socket for at
> least 10 seconds because remote DNS server is responding slowly or
> is down and based on a query volume it can effectively overload
> the cache server.
>
> Initially we thought we could fix it with "
> resolver-query-timeout", but after bind code analysis it seems
> that everything less that 10 seconds would be ignored, it would be
> great to mention this in the documentation.
> So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c
> and recompile named, but  it would be nice to understand why 10
> seconds as minimum value were selected in the first place, see
> /lib/dns/resolver.c
>
> #define MAX_SINGLE_QUERY_TIMEOUT 9U
> #define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U) 
>
> snip
>
> void
> dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int
> seconds) {
> REQUIRE(VALID_RESOLVER(resolver));
> if (seconds == 0)
> seconds = DEFAULT_QUERY_TIMEOUT;
> if (seconds > MAXIMUM_QUERY_TIMEOUT)
> seconds = MAXIMUM_QUERY_TIMEOUT;
> if (seconds < MINIMUM_QUERY_TIMEOUT)
> seconds =  MINIMUM_QUERY_TIMEOUT;
> resolver->query_timeout = seconds;
> }
>
> We also tried to create local dummy zones for all these domains
> but since domains change frequently we started to block most
> active open resolvers and coordinate with local CERT.
>
> It would be nice to have some kind of rate limits for query volume
> of different hosts inside a single zone.
>
> Best regards,
>
> Ivo
>
>
> On 2/27/14 7:59 AM, Dmitry Rybin wrote:
>> Over 2 weeks ago begins flood. A lot of queries:
>>
>> niqcs.www.84822258.com 
>> vbhea.www.84822258.com 
>> abpqeftuijklm.www.84822258.com
>> 
>> adcbefmzidmx.www.84822258.com 
>> and many others.
>>
>> 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.
>>
>> Recursion clients via "rnds status" 300-500.
>>
>> I can try to use rate limit:
>> rate-limit {
>> nxdomains-per-second 10;
>> errors-per-second 10;
>> nodata-per-second 10;
>> };
>> I do not see an any improvement.
>>
>> Found one exit in this situation, add flood zones local.
>>
>> What can we do in this situation?
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> 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
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[Sten Carlsen]

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
> people to get out?
> 
> On Feb 27, 2014 10:13 AM, "Ivo" mailto:i...@nic.lv>> wrote:
> 
> 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 problem is that attacker selects few domains
> and generates queries with random hostnames which therefore are not
> in the cache and server has to perform recursion for each query. So
> each query will consume one udp or tcp socket for at least 10
> seconds because remote DNS server is responding slowly or is down
> and based on a query volume it can effectively overload the cache
> server.
> 
> Initially we thought we could fix it with " resolver-query-timeout",
> but after bind code analysis it seems that everything less that 10
> seconds would be ignored, it would be great to mention this in the
> documentation.
> So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c and
> recompile named, but  it would be nice to understand why 10 seconds
> as minimum value were selected in the first place, see
> /lib/dns/resolver.c
> 
> #define MAX_SINGLE_QUERY_TIMEOUT 9U
> #define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U) 
> 
> snip
> 
> void
> dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int
> seconds) {
> REQUIRE(VALID_RESOLVER(resolver));
> if (seconds == 0)
> seconds = DEFAULT_QUERY_TIMEOUT;
> if (seconds > MAXIMUM_QUERY_TIMEOUT)
> seconds = MAXIMUM_QUERY_TIMEOUT;
> if (seconds < MINIMUM_QUERY_TIMEOUT)
> seconds =  MINIMUM_QUERY_TIMEOUT;
> resolver->query_timeout = seconds;
> }
> 
> We also tried to create local dummy zones for all these domains but
> since domains change frequently we started to block most active open
> resolvers and coordinate with local CERT.
> 
> It would be nice to have some kind of rate limits for query volume
> of different hosts inside a single zone.
> 
> Best regards,
> 
> Ivo
> 
> 
> On 2/27/14 7:59 AM, Dmitry Rybin wrote:
>> Over 2 weeks ago begins flood. A lot of queries:
>>
>> niqcs.www.84822258.com 
>> vbhea.www.84822258.com 
>> abpqeftuijklm.www.84822258.com
>> 
>> adcbefmzidmx.www.84822258.com 
>> and many others.
>>
>> 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.
>>
>> Recursion clients via "rnds status" 300-500.
>>
>> I can try to use rate limit:
>> rate-limit {
>> nxdomains-per-second 10;
>> errors-per-second 10;
>> nodata-per-second 10;
>> };
>> I do not see an any improvement.
>>
>> Found one exit in this situation, add flood zones local.
>>
>> What can we do in this situation?
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> 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
> 
> 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
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!"
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[Ben Croswell]

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"  wrote:

>  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 problem is that attacker selects few domains and generates
> queries with random hostnames which therefore are not in the cache and
> server has to perform recursion for each query. So each query will consume
> one udp or tcp socket for at least 10 seconds because remote DNS server is
> responding slowly or is down and based on a query volume it can effectively
> overload the cache server.
>
> Initially we thought we could fix it with " resolver-query-timeout", but
> after bind code analysis it seems that everything less that 10 seconds
> would be ignored, it would be great to mention this in the documentation.
> So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c and
> recompile named, but  it would be nice to understand why 10 seconds as
> minimum value were selected in the first place, see /lib/dns/resolver.c
>
> #define MAX_SINGLE_QUERY_TIMEOUT 9U
> #define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U)
>
> snip
>
> void
> dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int seconds) {
> REQUIRE(VALID_RESOLVER(resolver));
> if (seconds == 0)
> seconds = DEFAULT_QUERY_TIMEOUT;
> if (seconds > MAXIMUM_QUERY_TIMEOUT)
> seconds = MAXIMUM_QUERY_TIMEOUT;
> if (seconds < MINIMUM_QUERY_TIMEOUT)
> seconds =  MINIMUM_QUERY_TIMEOUT;
> resolver->query_timeout = seconds;
> }
>
> We also tried to create local dummy zones for all these domains but since
> domains change frequently we started to block most active open resolvers
> and coordinate with local CERT.
>
> It would be nice to have some kind of rate limits for query volume of
> different hosts inside a single zone.
>
> Best regards,
>
> Ivo
>
>
> On 2/27/14 7:59 AM, Dmitry Rybin wrote:
>
> Over 2 weeks ago begins flood. A lot of queries:
>
> niqcs.www.84822258.com
> vbhea.www.84822258.com
> abpqeftuijklm.www.84822258.com
> adcbefmzidmx.www.84822258.com
> and many others.
>
> 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.
>
> Recursion clients via "rnds status" 300-500.
>
> I can try to use rate limit:
> rate-limit {
> nxdomains-per-second 10;
> errors-per-second 10;
> nodata-per-second 10;
> };
> I do not see an any improvement.
>
> Found one exit in this situation, add flood zones local.
>
> What can we do in this situation?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> 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
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[Ivo]

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 problem is that attacker selects few domains and
generates queries with random hostnames which therefore are not in the
cache and server has to perform recursion for each query. So each query
will consume one udp or tcp socket for at least 10 seconds because
remote DNS server is responding slowly or is down and based on a query
volume it can effectively overload the cache server.

Initially we thought we could fix it with " resolver-query-timeout", but
after bind code analysis it seems that everything less that 10 seconds
would be ignored, it would be great to mention this in the documentation.
So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c and
recompile named, but  it would be nice to understand why 10 seconds as
minimum value were selected in the first place, see /lib/dns/resolver.c

#define MAX_SINGLE_QUERY_TIMEOUT 9U
#define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U) 

snip

void
dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int seconds) {
REQUIRE(VALID_RESOLVER(resolver));
if (seconds == 0)
seconds = DEFAULT_QUERY_TIMEOUT;
if (seconds > MAXIMUM_QUERY_TIMEOUT)
seconds = MAXIMUM_QUERY_TIMEOUT;
if (seconds < MINIMUM_QUERY_TIMEOUT)
seconds =  MINIMUM_QUERY_TIMEOUT;
resolver->query_timeout = seconds;
}

We also tried to create local dummy zones for all these domains but
since domains change frequently we started to block most active open
resolvers and coordinate with local CERT.

It would be nice to have some kind of rate limits for query volume of
different hosts inside a single zone.

Best regards,

Ivo


On 2/27/14 7:59 AM, Dmitry Rybin wrote:
> Over 2 weeks ago begins flood. A lot of queries:
>
> niqcs.www.84822258.com
> vbhea.www.84822258.com
> abpqeftuijklm.www.84822258.com
> adcbefmzidmx.www.84822258.com
> and many others.
>
> 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.
>
> Recursion clients via "rnds status" 300-500.
>
> I can try to use rate limit:
> rate-limit {
> nxdomains-per-second 10;
> errors-per-second 10;
> nodata-per-second 10;
> };
> I do not see an any improvement.
>
> Found one exit in this situation, add flood zones local.
>
> What can we do in this situation?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind vs flood

[Peter Andreev]

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 who sending these
queries and ask them to stop.




2014-02-27 9:59 GMT+04:00 Dmitry Rybin :

> Over 2 weeks ago begins flood. A lot of queries:
>
> niqcs.www.84822258.com
> vbhea.www.84822258.com
> abpqeftuijklm.www.84822258.com
> adcbefmzidmx.www.84822258.com
> and many others.
>
> 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.
>
> Recursion clients via "rnds status" 300-500.
>
> I can try to use rate limit:
> rate-limit {
> nxdomains-per-second 10;
> errors-per-second 10;
> nodata-per-second 10;
> };
> I do not see an any improvement.
>
> Found one exit in this situation, add flood zones local.
>
> What can we do in this situation?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Bind vs flood

[Dmitry Rybin]

Over 2 weeks ago begins flood. A lot of queries:

niqcs.www.84822258.com
vbhea.www.84822258.com
abpqeftuijklm.www.84822258.com
adcbefmzidmx.www.84822258.com
and many others.

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.


Recursion clients via "rnds status" 300-500.

I can try to use rate limit:
rate-limit {
nxdomains-per-second 10;
errors-per-second 10;
nodata-per-second 10;
};
I do not see an any improvement.

Found one exit in this situation, add flood zones local.

What can we do in this situation?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users