Re: How to return REFUSED
On 06.05.21 18:41, Axel Rau wrote: This NS has some other clients in the DMZ LAN, so I need Views. you need multiple views if you are going to provide multiple versions of the same zones, different forwardings for different domains or alike. Not just if you have other clients. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux is like a teepee: no Windows, no Gates and an apache inside... ___ 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: How to return REFUSED
> With 2 views ddos trace looks much better: > > 17:40:21.483188 186.149.116.55.80 > 91.216.35.171.53: [no udp cksum] 1+ > > RRSIG? pizzaseo.com.(30) (ttl 242, id 21165, len 58) > 17:40:21.483470 91.216.35.171.53 > 186.149.116.55.80: [udp sum ok] 1 > > Refused- q: RRSIG? pizzaseo.com. 0/0/0(30) (DF) (ttl 64, id 0, len 58) > > Hopefully, they give up in some days, if there is no amplification any > more. They don't ever give up. I see one or two of these RRSIG? pizzaseo.com. queries every few days and even when I agressively packet filter the ones that appear likely to be real probes from malicious actors as opposed to bogus queries from forged ip addresses targetting innocents, return "refused" for the others and minimise the number of "refused" packets I send out by using "errors-per-second 1", they still keep on trying. The most recent one I've seen was three days ago but there could have been more since then that hit the packet filters when I wasn't paying attention. Regards, Peter Coghlan. ___ 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: How to return REFUSED
> Am 06.05.2021 um 18:41 schrieb Axel Rau : > > This NS has some other clients in the DMZ LAN, so I need Views. With 2 views ddos trace looks much better: 17:40:21.483188 186.149.116.55.80 > 91.216.35.171.53: [no udp cksum] 1+ RRSIG? pizzaseo.com.(30) (ttl 242, id 21165, len 58) 17:40:21.483470 91.216.35.171.53 > 186.149.116.55.80: [udp sum ok] 1 Refused- q: RRSIG? pizzaseo.com. 0/0/0(30) (DF) (ttl 64, id 0, len 58) Hopefully, they give up in some days, if there is no amplification any more. I have now 2 views. All zones are in the internal view. The (only) external zones in external view use in-view to reference them in internal view. axfr seems to work,, notify still to be tested. If someone wants to play with the staging server please: dig ANY chaos1.de. @ns3.lrau.net. Any feedback welcome, Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius signature.asc Description: Message signed with OpenPGP ___ 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: How to return REFUSED
> Am 05.05.2021 um 22:06 schrieb Kevin Darcy via bind-users
> mailto:bind-users@lists.isc.org>>:
>
> I just checked the ARM, and it denotes that "match-recursive-only" (boolean)
> still exists for views. So, you might be able to set up a special view with
> that, as well as a negated match-clients, specifying allow-query { none; }.
> Put it as the first view, and both non-recursive queries, and queries from
> your "recursive-users" ACL, will fall through to subsequent views.
>
> P.S. ISC's "understanding views" knowledgebase article doesn't mention
> match-recursive-only, so there is a discrepancy there. Either the feature has
> been removed, and the ARM documentation hasn't been updated to reflect it, or
> the knowledgebase article only focuses on the most common view-matching
> criteria, omitting match-recursive-only, since the use cases for that are
> very rare.
Thanks, Kevin for your quick response, which let me start converting to views,
Axel
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius
signature.asc
Description: Message signed with OpenPGP
___
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: How to return REFUSED
> Am 06.05.2021 um 12:05 schrieb Matus UHLAR - fantomas : > > > Which named version do you run? 9.16.15 > do you use views? No, but after reading Tonys response, I’m now starting to convert my config to views. Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius signature.asc Description: Message signed with OpenPGP ___ 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: How to return REFUSED
> Am 06.05.2021 um 16:45 schrieb Tony Finch :
>
> Axel Rau wrote:
>
>> I have,
>>
>> allow-query { any; };
>> allow-query-cache { recursive-users; };
>> allow-recursion { recursive-users; };
>>
>> How can I make sure that none recursive-users get a REFUSED if query is
>> recursive?
>
> Weird! I think your config should do what you want so I wonder why it
> isn't working. Your server is responding to the problem queries with a
> referral from the root zone, so have you configured your server with a
> local authoritative copy of the root?
Yes.
>
> There's a broader issue here:
>
> Usually when you have a server that is providing recursive service to
> anyone, it is best to set the allow-query ACL to cover just your users, so
> everyone else gets REFUSED.
>
> This means that your recursive server cannot also be used as an
> authoritative server advertised in NS records. Your public authoritative
> servers should be authoritative-only and not offer recursion to anyone.
>
>> PS: I want to minimize the responses to this amplification attack:
>
> Ooh, RRSIG queries are fun. They are like a stealth ANY query.
>
> BIND has several tools for dealing with this kind of junk:
>
> * RRL is very effective
>
> * minimal-any also minimizes responses to RRSIG queries
>
> * minimal-responses can also help to reduce packet sizes
>
> Your server is responding with a referral from the root, so minimal-any
> won't have any effect on the response. And because it's a referral, the
> glue etc. is not optional, so there's nothing that minimal-responses can
> omit. So in your situation the most useful things to do would be:
>
> * tighten up your allow-query ACL
>
> * if you can't do that, use RRL (you can add recursive-users to the
>exempt-clients list)
>
> * configure separate views for recursive-users and others; do not
>include the root zone in your external view
Currently, I have:
minimal-responses yes;
require-server-cookie yes;
rate-limit {
responses-per-second 5;
exempt-clients { recursive-users; };
};
which do not really help.
This NS has some other clients in the DMZ LAN, so I need Views.
I gave up with views years ago and I have now to learn to use them with all the
recent stuff, like in-view.
in-view can be helpful to reference the auth zones in the local view, I guess.
Thanks for your your comprehensive explanation,
Axel
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius
signature.asc
Description: Message signed with OpenPGP
___
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: How to return REFUSED
Axel Rau wrote:
> I have,
>
> allow-query { any; };
> allow-query-cache { recursive-users; };
> allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is
> recursive?
Weird! I think your config should do what you want so I wonder why it
isn't working. Your server is responding to the problem queries with a
referral from the root zone, so have you configured your server with a
local authoritative copy of the root?
There's a broader issue here:
Usually when you have a server that is providing recursive service to
anyone, it is best to set the allow-query ACL to cover just your users, so
everyone else gets REFUSED.
This means that your recursive server cannot also be used as an
authoritative server advertised in NS records. Your public authoritative
servers should be authoritative-only and not offer recursion to anyone.
> PS: I want to minimize the responses to this amplification attack:
Ooh, RRSIG queries are fun. They are like a stealth ANY query.
BIND has several tools for dealing with this kind of junk:
* RRL is very effective
* minimal-any also minimizes responses to RRSIG queries
* minimal-responses can also help to reduce packet sizes
Your server is responding with a referral from the root, so minimal-any
won't have any effect on the response. And because it's a referral, the
glue etc. is not optional, so there's nothing that minimal-responses can
omit. So in your situation the most useful things to do would be:
* tighten up your allow-query ACL
* if you can't do that, use RRL (you can add recursive-users to the
exempt-clients list)
* configure separate views for recursive-users and others; do not
include the root zone in your external view
Tony.
--
f.anthony.n.finchhttps://dotat.at/
The Minch: North 6 or 7, backing northwest 3 to 5. Rough or very rough
at first northeast of skye, otherwise slight or moderate. Wintry
showers. Good, occasionally poor.
___
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: How to return REFUSED
On 05.05.21 21:09, Axel Rau wrote:
allow-query { any; };
allow-query-cache { recursive-users; };
allow-recursion { recursive-users; };
How can I make sure that none recursive-users get a REFUSED if query is
recursive?
I thought this is the default...
PS: I want to minimize the responses to this amplification attack:
19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+
RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q:
RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS
m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS b.gtld-servers.net.,
com. NS d.gtld-servers.net., com. NS e.gtld-servers.net., com. NS
l.gtld-servers.net., com. NS f.gtld-servers.net., com. NS h.gtld-servers.net.,
com. NS i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS
k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net. A
192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net. A
192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net. A
192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net. A
192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A
192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A
192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A
192.5.6.30, m.gtld-servers.net. 2001:501:b1f9:
:30(490) (ttl 63, id 11754, len 518)
... exactly because of this reason.
Which named version do you run?
do you use views?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!
___
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: How to return REFUSED
[ Classification Level: GENERAL BUSINESS ]
I just checked the ARM, and it denotes that "match-recursive-only"
(boolean) still exists for views. So, you might be able to set up a special
view with that, as well as a negated match-clients, specifying allow-query
{ none; }. Put it as the first view, and both non-recursive queries, and
queries from your "recursive-users" ACL, will fall through to subsequent
views.
- Kevin
P.S. ISC's "understanding views" knowledgebase article doesn't mention
match-recursive-only, so there is a discrepancy there. Either the feature
has been removed, and the ARM documentation hasn't been updated to reflect
it, or the knowledgebase article only focuses on the most common
view-matching criteria, omitting match-recursive-only, since the use cases
for that are very rare.
On Wed, May 5, 2021 at 3:10 PM Axel Rau wrote:
> I have,
>
> allow-query { any; };
> allow-query-cache { recursive-users; };
> allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is
> recursive?
>
> Axel
>
> PS: I want to minimize the responses to this amplification attack:
> - - -
> 19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+
> RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
> 19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q:
> RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS
> m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS
> b.gtld-servers.net., com. NS d.gtld-servers.net., com. NS
> e.gtld-servers.net., com. NS l.gtld-servers.net., com. NS
> f.gtld-servers.net., com. NS h.gtld-servers.net., com. NS
> i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS
> k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net.
> A 192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net.
> A 192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net.
> A 192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net.
> A 192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A
> 192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A
> 192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A
> 192.5.6.30, m.gtld-servers.net. 2001:501:b1f9::30(490) (ttl 63, id
> 11754, len 518)
> - - -
> ---
> PGP-Key: CDE74120 ☀ computing @ chaos claudius
>
> ___
> 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
How to return REFUSED
I have,
allow-query { any; };
allow-query-cache { recursive-users; };
allow-recursion { recursive-users; };
How can I make sure that none recursive-users get a REFUSED if query is
recursive?
Axel
PS: I want to minimize the responses to this amplification attack:
- - -
19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+
RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q:
RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS
m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS b.gtld-servers.net.,
com. NS d.gtld-servers.net., com. NS e.gtld-servers.net., com. NS
l.gtld-servers.net., com. NS f.gtld-servers.net., com. NS h.gtld-servers.net.,
com. NS i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS
k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net. A
192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net. A
192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net. A
192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net. A
192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A
192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A
192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A
192.5.6.30, m.gtld-servers.net. 2001:501:b1f9::30(490) (ttl 63, id 11754,
len 518)
- - -
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius
signature.asc
Description: Message signed with OpenPGP
___
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
