[Dnsmasq-discuss] socket activation support (systemd)

[kuehn.michael at icloud.com]

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.

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

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20241001/9ddf7568/attachment.htm>