On 2020-09-21, Predrag Punosevac <punoseva...@gmail.com> wrote: > As of the port blocking unfortunately I am old enough to remember this > post > > http://cr.yp.to/djbdns/tcp.html#why > > and the remark that TCP is only needed for records larger than 512 > bytes. > > "You want to publish record sets larger than 512 bytes. (This is almost > always a mistake.)" > > I had no need for TCP port 53 to be open. Until month and a half ago > things worked as expected and I have more important things to do than to > fix things which don't appear to be broken.
DNS is fairly resilient so it can often "work" in a degraded fashion with the only noticeable problem being some slowness, but relying on this means that when things are a bit more broken or the situation changes it will be unusable. Even in cases where there are no large record sets, it is common for modern authoritative servers to employ RRL (response rate limiting) for UDP queries. One common method involves replying with a short response with the TC flag set (truncated, querier should retry over TCP) when they receive high request volumes from a particular source network (often spoofed, using the authoritative server as a "packet amplifier" - small queries generate a larger response directed at the spoofed address). The handshake needed for establishing a TCP connection makes it hard to spoof the source address of a query (trivial for UDP) allowing legitimate connections to make it through while not acting as a reliable packet amplifier. > The following > > https://www.openbsd.org/faq/pf/ > > is also evolving. Honestly it hasn't had a thorough refresh/review since before PF syntax changed to nat-to over 10 years ago, it's only had iterative changes since then - it will get you up and running but imho it's not a great basis for writing a maintainable and well-performing ruleset using current features. Tagging is only mentioned in "advanced configuration", received-on isn't shown at all, no use of interface groups (those three I'd consider pretty basic use), nothing about priority or queues or flow queues (I guess these are a bit more advanced but I'd consider essential for both setups with low line capacity, and larger scale setups where you have high speed ports feeding lower speed lines - either NNIs with leased line carriers or where you're controlling flows into radio links of say a hundred Mb from a gigabit port etc).
