------- 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!)...
