------- Original Message ------- On Wednesday, July 19th, 2023 at 10:58 PM, Stuart Henderson <s...@spacehopper.org> wrote:
> For rules that pass traffic to your authoritative DNS servers, > I don't think you need much longer than the time taken to answer a > query. So could be quite a bit less. Right good point, I will add custom state timeouts for this specific UDP pass rule on port 53. > Usually carp/ospf will enter the state table before the machines start > seeing large amounts of packets and stay there, which is what you would > normally want. If the state table is full, you have more problem > opening new connections that require state to be added than you do > maintaining existing ones. > > fwiw I typically use this on ospf+carp machines, "pass quick proto > {carp, ospf} keep state (no-sync) set prio 7" That's very interesting, I never realized there was a simple priority system ready to use in PF without the need of setting up any queues. Probably the "set prio 7" option on OSPF+CARP pass rules will juts do the trick and I will definitely also implement this. > DNS server software is written with this type of traffic in mind, and > has more information available (from inside the DNS request packet) > to make a decision about what to do with it, than is available in a > general-purpose packet filter like PF. > > Also it stores the tracking information in data structures that have > been chosen to make sense for this use (and common DNS servers default > to masking on common subnet sizes, reducing the amount they have to > store compared to tracking the full IP address). > > http://man.openbsd.org/nsd.conf#rrl > https://bind9.readthedocs.io/en/latest/reference.html#response-rate-limiting > https://www.knot-dns.cz/docs/2.4/html/reference.html#module-rrl Too bad I use PowerDNS, it does not seem to offer much parameters related to rate-limiting for UDP but for TCP I found at least max-tcp-connections. Maybe it's time for a change as Gabor mentions his tests in his reply (thanks btw!)...