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.htmlDisclaimer: 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.
This of course applies only when dnsmasq is used only for DNS and if it should listen only on.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
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.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.
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.5) there are more benefits outlined in the talk like nicer integration with faster system boots and etc.
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.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 Thank you micha
-- Petr Menšík Software Engineer, RHEL Red Hat,https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
