> What even worse as top quoting? Mixing top qouting with inline qouting
On Wed, Oct 02, 2024 at 01:13:03AM +0200, Petr Menšík wrote: > I am not sure systemd.socket can listen both on UDP and TCP, to pass both > sockets into dnsmasq when it starts. For a properly initialized dnsmasq it > is needed to listen on both. Most other services I have seen with socket > activation use it with TCP socket only. It is much easier with that. I have > not found systemd-resolved.socket for example on Fedora 40. > > socket activation cannot work well with bind-dynamic. If bind-dynamic style > is enough, it should be okay. But it kind of allows only --listen-address > alternative, I think. Which often might would be useful enough. > > I think what would need to be added is accepting open listening sockets from > daemon and install them instead of creating own socket. Probably would need > libsystemd linking at compile time. sd_notify support might be useful > addition too. > > But systemd socket handling has also limitations. For example it rate limits > connections over limit, which may DoS the service. That were I think > motivation for disabling sshd.socket activation in Fedora about a year ago. > Triggering the limit for some time disabled temporarily the service for > everyone, which is not ideal also for DNS. It should be carefully tested. > > Cheers, > Petr > > On 01/10/2024 17:49, kuehn.michael--- via Dnsmasq-discuss wrote: > > Hi, > > > > i found the some threads discussing this already (in 2023 and decades > > before that), including: > > - > > https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg17151.html > > > > Disclaimer: i won’t get into the philosophical stance reg. uselessness > > or “overblown”-ness of systemd, as this often is religious, tedious and > > out of scope and also i think mailing-lists are not a good format for > > those long back-and-forth takes) - but systemd becomes more and more > > ubiquitous and this is for good reasons and what ever your gripes with > > systemd are, it’s not a niche. In fact it’s the default in most > > mainstream distributions already > > (https://en.wikipedia.org/wiki/Systemd#Adoption) > > > > There was one reply from Simon that he desires to better understand > > systemd and/or socket activation, which i’m not sure is still needed but > > if it is, i think this talk is very good as a starting point: > > https://youtu.be/TyMLi8QF6sw (socket activation part starts at 18:07). > > > > In previous threads here were often some questions about use-cases. My > > personal one is #4 but i think they are all valid on their own. > > > > > > Having systemd managing the socket has multiple benefits: > > > > 1) restarts of dnsmasq.service would not loose DNS queries as the > > dnsmasq.socket is not restarted and would buffer those messages until > > the service is back up again and can process those. This means less > > frictions for users when maintenance is done by admins reg. dnsmasq > > upgrades etc. > > Okay. I never understood motivation for starting DNS caching service by > socket activation. But avoiding lost messages during update sounds like not > bad idea. Although retries should be common for client applications, so fast > restart should not cause significant regressions. > > But there need to be cases how to reopen listening sockets anyway. I expect > it just moves to systemd daemon service or something similar. But some race > condition cannot completely disappear during updates. > > > > > 2) .socket in systemd has a lot of options for administration: > > https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html > > incl. resource control, security, behavior, etc. > > > > 3) having the socket managed by systemd allows capabilities from the > > binaries dropped to open ports <1024 (DNS w/ port 53 definitely falls > > under that). So security minded admins could drop the > > CAP_NET_BIND_SERVICE from dnsmasq > This of course applies only when dnsmasq is used only for DNS and if it > should listen only on. Suggestion: Start the "socket adventure" with "only DNS". > > 4) and finally, what motivated me to bring this up here _again_: better > > support for (rootless) containerization. For example in podman: If you > > want to run dnsmasq completely rootless with a container, current > > rootless networks provided by podman loose the source IPs. See > > https://github.com/containers/podman/issues/8193#issuecomment-2386247390 > > This is a “problem" when using pi-hole (pi-hole FTL is based on > > dnsmasq), as you loose a lot of visibility about the clients on the > > network (and it breaks features that rely on a correct source-ip). Right > > now, this limitation prevents users from running pi-hole/dnsmasq in a > > rootless mode. > Right, If podman avoids privilege requirement by making proxy, then it would > need to support some proxy protocol and dnsmasq would need to understand as > well. Passing pre-created listening sockets to dnsmasq to operate on them > would be simpler and safer. > > > > 5) there are more benefits outlined in the talk like nicer integration > > with faster system boots and etc. > I am not sure it makes faster boot response. Dnsmasq does not support > Type=notify reporting of readiness, which might be more interesting for me. > Typically there is nothing useful to provide from cache until network > routing it ready for sending forwarded queries outside. I see a little > benefits starting earlier, unless caching /etc/hosts is significant speedup. > And we have nss-lookup.target, I am not sure if socket activated service cat > make it started also. > > > > I really hope that socket-activation is considered, this would improve > > dnsmasq's integration and acceptability on a lot of fronts. If there are > > any questions or concerns left, i’m more than happy to help. Explain why waiting for others. > > More readings (if interested) about this can be found here: > > - http://0pointer.de/blog/projects/the-biggest-myths (point 3 mentions > > socket activation) > > - http://0pointer.de/blog/projects/socket-activated-containers.html Groeten Geert Stappers -- Silence is hard to parse _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
