How to return REFUSED

[Axel Rau]

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. AAAA 2001:501:b1f9::30(490) (ttl 63, id 11754, len 518)
- - -
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius

[Kevin Darcy via bind-users]

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

Post by Axel Rau
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
- - -
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)
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. AAAA 2001:501:b1f9::30(490) (ttl 63, id
11754, len 518)
- - -
---
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

[Axel Rau]

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

[Matus UHLAR - fantomas]

Post by Axel Rau
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...

Post by Axel Rau
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)

: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, ***@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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Axel Rau]

Post by Matus UHLAR - fantomas
Which named version do you run?

9.16.15

Post by Matus UHLAR - fantomas
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

[Tony Finch]

Post by Axel Rau
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.
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.finch <***@dotat.at> https://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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Axel Rau]

Post by Tony Finch

Post by Axel Rau
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.

Post by Tony Finch
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.
Ooh, RRSIG queries are fun. They are like a stealth ANY query.
* 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
* 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

[Axel Rau]

Post by 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

[Peter Coghlan]

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.

[Matus UHLAR - fantomas]

Post by Axel Rau
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, ***@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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users