[Dnsmasq-discuss] socket activation support (systemd)

Tue Oct 1 23:13:03 UTC 2024

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.
>
> 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.
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20241002/675ce84e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9736 bytes
Desc: OpenPGP public key
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20241002/675ce84e/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20241002/675ce84e/attachment-0001.sig>