Just my opinion.
Don't rate limit tcp. The RRL feature in Bind only rate limits UDP.
UDP is connection-less and the source address can be forged, generating
DDOS traffic to a 3rd party.
Proper DNS software will fall back to TCP. Because TCP is connection
based, much harder to forge source address.
Lyle
On 8/3/22 08:30, Robert Moskowitz wrote:
Thanks. I will look into this.
On 8/3/22 07:47, Victor Johansson via bind-users wrote:
Hey,
I just want to add that there is a better way to do this in iptables
with hashlimit. The normal rate limit in iptables is too crude.
Below is an example from the rate-limit-chain, to which you simply
send all port 53 traffic from the INPUT chain (make sure to exclude
127.0.0.1/127.0.0.53 though :) ).
-A INPUT -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
-A INPUT -p tcp -m tcp --dport 53 -j DNS-RATE-LIMIT
-A DNS-RATE-LIMIT -s 127.0.0.1/32 -m comment --comment "Dont
rate-limit localhost" -j RETURN
-A DNS-RATE-LIMIT -m hashlimit --hashlimit-upto 100/sec
--hashlimit-burst 300 --hashlimit-mode srcip --hashlimit-name
DNS-drop --hashlimit-htable-expire 2000 -j ALLOW
-A DNS-RATE-LIMIT -m limit --limit 1/sec -j LOG --log-prefix "DNS-drop: "
-A DNS-RATE-LIMIT -m comment --comment "ansible[dns rate limiting]"
-j DROP
//Victor
On 8/2/22 23:16, Michael De Roover wrote:
For my servers I'm using iptables rules to achieve ratelimiting.
They look as follows:
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent
--update --seconds 600 --hitcount 4 --name DEFAULT --mask
255.255.255.255 --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent
--set --name DEFAULT --mask 255.255.255.255 --rsource
It should be fairly trivial to convert these to use UDP 53, and
tweak the timings you want. These rules are intended to allow 4
connections (which normally should be entire SMTP transactions)
every 10 minutes. Since I have 2 edge nodes with these rules, that
is doubled to 8 connections total. If you're an authoritative name
server only, realistically mostly recursors / caching servers would
query your servers and not too often. You can easily restrict
traffic here. If you're a recursor too, this becomes a bit more
complicated.
Regarding the legitimate queries, it would be prudent to allow
common recursors (Google, Cloudflare, Quad9 etc) to have exceptions
to this rule. Just allow their IP addresses to send traffic either
unrestricted, or using a more relaxed version of the above.
HTH,
Michael
On Tue, 2022-08-02 at 16:02 -0400, Robert Moskowitz wrote:
Recently I have been having problems with my server not responding
to my
requests. I thought it was all sorts of issues, but I finally
looked at
the logs and:
Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.194.4#11205
(.): view external: query (cache) './A/IN' denied
Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.216.196#64956 (.): view external: query (cache) './A/IN' denied
Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80
64.68.114.141#39466
(.): view external: query (cache) './A/IN' denied
Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80
209.197.198.45#13280 (.): view external: query (cache) './A/IN' denied
Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.202.117#41955 (.): view external: query (cache) './A/IN' denied
Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80
62.109.204.22#4406
(.): view external: query (cache) './A/IN' denied
Aug 2 15:47:49 onlo named[6155]: client @0xa9420720 64.68.104.9#38518
(.): view external: query (cache) './A/IN' denied
Aug 2 15:47:50 onlo named[6155]: client @0xaa882dc8
114.29.202.117#9584
(.): view external: query (cache) './A/IN' denied
grep -c denied messages
45868
And that is just since Jul 31 3am.
This is fairly recent so I never looked into what I might do to
protect
against this. I am the master for my domain, so I do need to allow
for
legitimate queries.
Any best practices on this?
I am running bind 9.11.4
thanks
--
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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
