<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Cheers,<br>
Petr<br>
</p>
<div class="moz-cite-prefix">On 01/10/2024 17:49, kuehn.michael---
via Dnsmasq-discuss wrote:<br>
</div>
<blockquote type="cite"
cite="mid:F7FEC2EE-754E-4781-9548-FFDD06D42B26@icloud.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>Hi,</div>
<div><br>
</div>
<div>i found the some threads discussing this already (in 2023 and
decades before that), including:</div>
<div>-
<a class="moz-txt-link-freetext" href="https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg17151.html">https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg17151.html</a></div>
<div><br>
</div>
<div>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 (<a
href="https://en.wikipedia.org/wiki/Systemd#Adoption"
moz-do-not-send="true" class="moz-txt-link-freetext">https://en.wikipedia.org/wiki/Systemd#Adoption</a>)</div>
<div><br>
</div>
<div>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: <a class="moz-txt-link-freetext" href="https://youtu.be/TyMLi8QF6sw">https://youtu.be/TyMLi8QF6sw</a> (socket
activation part starts at 18:07).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div>Having systemd managing the socket has multiple benefits:</div>
<div><br>
</div>
<div>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.</div>
</blockquote>
<p>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.</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:F7FEC2EE-754E-4781-9548-FFDD06D42B26@icloud.com">
<div><br>
</div>
<div>2) .socket in systemd has a lot of options for
administration:
<a class="moz-txt-link-freetext" href="https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html">https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html</a>
incl. resource control, security, behavior, etc.</div>
<div><br>
</div>
<div>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</div>
</blockquote>
This of course applies only when dnsmasq is used only for DNS and if
it should listen only on.<br>
<blockquote type="cite"
cite="mid:F7FEC2EE-754E-4781-9548-FFDD06D42B26@icloud.com">
<div><br>
</div>
<div>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
<a class="moz-txt-link-freetext" href="https://github.com/containers/podman/issues/8193#issuecomment-2386247390">https://github.com/containers/podman/issues/8193#issuecomment-2386247390</a>
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.</div>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:F7FEC2EE-754E-4781-9548-FFDD06D42B26@icloud.com">
<div><br>
</div>
<div>5) there are more benefits outlined in the talk like nicer
integration with faster system boots and etc.</div>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:F7FEC2EE-754E-4781-9548-FFDD06D42B26@icloud.com">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>More readings (if interested) about this can be found here:</div>
<div>- <a class="moz-txt-link-freetext" href="http://0pointer.de/blog/projects/the-biggest-myths">http://0pointer.de/blog/projects/the-biggest-myths</a> (point 3
mentions socket activation)</div>
<div>-
<a class="moz-txt-link-freetext" href="http://0pointer.de/blog/projects/socket-activated-containers.html">http://0pointer.de/blog/projects/socket-activated-containers.html</a></div>
<div><br>
</div>
<div>Thank you</div>
<div>micha</div>
<span style="white-space: pre-wrap">
</span></blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>