Linux connection tracking and (Slow) DNS
kb.isc.org
Linux connection tracking and (Slow) DNS
1–10 of 17 posts
Re: Linux connection tracking and (Slow) DNS
#2I’m concerned that this is output generated by an LLM (specifically chatgpt) as the writing style is eerily similar.
iptables conntrack is indeed a huge menace, but you should bypass conntrack entirely for local network connections as you don’t need it.
The only thing conntrack would give you for local requests is better logging, but YAGNI.
Re: Linux connection tracking and (Slow) DNS
#3The fun part is that in some cases just listing the iptables rules with an iptables -L will cause it to load the conntrack module and the default max for this is very low for anything that is a DNS server or perform a lot of DNS lookups. That's why it's a good idea to always set the sysctl nf_conntrack_max value quite high even if you aren't using conntrack. The actual sysctl key for nf_conntrack is different depending on the version of the kernel, it's net.netfilter.nf_conntrack_max nowadays.
Re: Linux connection tracking and (Slow) DNS
#4The fun part is that in some cases just listing the iptables rules with an iptables -L will cause it to load the conntrack module and the default max for this is very low for anything that is a DNS server or perform a lot of DNS lookups. That's why it's a good idea to always set the sysctl nf_conntrack_max value quite high even if you aren't using conntrack. The actual sysctl key for nf_conntrack is different dependi…
There is also a trap, which is that setting this in /etc/sysctl.conf or /etc/sysctl.d doesn't work, because the module isn't always yet loaded when those are set.
One fix is to load nf_conntrack at boot by adding it to the module load list
https://bugs.launchpad.net/bugs/1922778 https://github.com/canonical/microk8s/issues/4462
On a related note, the sosreport tool which collects outputs of a zillion different commands for diagnostics purposes, goes to great lengths and CI tests that no kernel modules are loaded by any of the plugins, for basically this same reason.
e.g. If the modules aren't already loaded, it will avoid running iptables -L and various other tricks: https://github.com/sosreport/sos/issues/1435 https://github.com/sosreport/sos/issues/2978
Re: Linux connection tracking and (Slow) DNS
#5I’m concerned that this is output generated by an LLM (specifically chatgpt) as the writing style is eerily similar. iptables conntrack is indeed a huge menace, but you should bypass conntrack entirely for local network connections as you don’t need it. The only thing conntrack would give you for local requests is better logging, but YAGNI.
Doesn't seem like LLM output to me. Rather, it seems like unnecessary text padding with pseudo stories to please (possibly outdated) SEO strategies.
Re: Linux connection tracking and (Slow) DNS
#6This sounds like bad advice, I don't know why ISC is pushing this... they would be better off trying to make DNS a TCP-only service to stop amplification attacks.
Re: Linux connection tracking and (Slow) DNS
#7This sounds like bad advice, I don't know why ISC is pushing this... they would be better off trying to make DNS a TCP-only service to stop amplification attacks.
> This sounds like bad advice
Please elaborate.
As they say a typical DNS request comes in as one packet and is replied in one packet, there is no ongoing connection so there's no point keeping tracking information.
The implication of not tracking the connection is that any packets will have to match a more specific rule than the "allow established,related" at the top of the firewall chain.
> they would be better off trying to make DNS a TCP-only service to stop amplification attacks.
Sure, lets get literally everyone on the intenet to agree to a new version of DNS that uses TCP...
Even if you do that - the problem moves from conntrack filling up we can fill up on ephemeral ports stuck in TIME_WAIT because some genius thought a service that doesn't maintain a connection should use TCP
Re: Linux connection tracking and (Slow) DNS
#8This sounds like bad advice, I don't know why ISC is pushing this... they would be better off trying to make DNS a TCP-only service to stop amplification attacks.
If you want to stop UDP DNS from being able to amplify, require bigger query datagrams.
Re: Linux connection tracking and (Slow) DNS
#9This sounds like bad advice, I don't know why ISC is pushing this... they would be better off trying to make DNS a TCP-only service to stop amplification attacks.
> This sounds like bad advice Please elaborate. As they say a typical DNS request comes in as one packet and is replied in one packet, there is no ongoing connection so there's no point keeping tracking information. The implication of not tracking the connection is that any packets will have to match a more specific rule than the "allow established,related" at the top of the firewall chain. > they would be better off…
> lets get literally everyone on the intenet to agree to a new version of DNS that uses TCP
That's already done. DNS servers already all speak both TCP and UDP. Try "dig google.com @8.8.8.8 +tcp".
Re: Linux connection tracking and (Slow) DNS
#10This sounds like bad advice, I don't know why ISC is pushing this... they would be better off trying to make DNS a TCP-only service to stop amplification attacks.
TCP is less efficient for request-response protocol. The root of the problem (DDoS with amplification) IMHO is not DNS but ISPs which allow to spoof source addresses. Most don’t allow. RFC2827 (BCP38) was published >20 years ago and the problem was not new even back then. How bad guys find ISP (or hostings) permitting src IP spoofing? Is there a way to encourage such ISP to follow BCP38?