Bug#1091864: tech-ctte: Avahi and systemd-resolved cannot a run mDNS responder at the same time

Michael Biebl biebl at debian.org
Tue Feb 11 15:18:04 GMT 2025


Hi,

as said, I wanted to add a few more remarks which hopefully make you 
better understand my reasoning why I think building systemd with 
"-Ddefault-mdns=no" is the right course of action for the time being.


avahi-daemon is currently installed on about 50% on all machines 
according to popcon. This is basically a result of task-desktop 
recommending it explicitly, cups recommending it and gnome having a hard 
dependency on it.
So it's safe to say that on desktop installations and installations with 
printing support, avahi-daemon will be available.
For a very long time, Avahi has been the only mDNS implementation 
available in Debian. The observation that the Avahi code base is old and 
showing signs of age is correct. After Lennart had lost interest in 
Avahi, Trent Lloyd had basically been its sole maintainer for many 
years. Thankfully, the situation has changed upstream and a new team has 
formed at [0] which actively handles issues and pull requests.

mDNS support in resolved is still relatively new and not complete: E.g. 
it misses the publishing parts and I'm not sure if systemd upstream has 
plans to implement this kind of functionality, i.e. it is unclear to me 
if and how it could supplant Avahi fully at this point.



Second, in [1], Luca argued that "resolved needs to work out of the box 
upon installation, and that includes mDNS".

I understand (and actually think it's a laudable goal), that Luca wants 
to have mDNS (resolve functionality) available for basically everyone. But:
a/ systemd-resolved is not installed by default
b/ enabling mDNS functionality globally (i.e. having MulticastDNS=yes as 
default in /etc/systemd/resolved.conf) does not mean it will work out of 
the box. One has to enable it explicitly "per link" as well.
If you are using networkd, you can achieve that by setting 
"MulticastDNS=yes" [1] (the default being no).
NetworkManager has a similar switch, and ifupdown has no equivalent 
config option.

It is thus incorrect to say, that by building resolved with 
"-Ddefault-mdns=yes" it would work out of the box. It will always 
require explicit configuration anyway.
So I find Luca's argument very weak.



Third, I also find the idea of one (unrelated) package silently 
disabling functionality of another package upon installation via the 
suggested drop-in snippet in [2] an anti pattern.
I asked Simon, whose opinion I value greatly and who has been 
co-maintaining avahi [3]. He basically agreed and called it a "strange 
action at a distance".
Taking this idea further, would you consider it a good idea, if say 
installing rsyslog would ship a config snippet disabling the journald 
functionality? I would not and would find this behaviour very unpredictable.

No other distribution I know of does it this way. Fedora and Ubuntu e.g. 
instead build systemd with "-Ddefault-mdns=no".



Fourth, limiting this decision to trixie only.
In principal I agree that this decision should be time limited and not 
absolute. Assuming though, that the overall situation does not change 
significantly in forky, we will have this dispute all over again.

Wouldn't it be better to tie this decision to certain constraints?
One such change could be that systemd-resolved is installed by default 
(a change that hopefully is decided Debian wide) or systemd-resolved 
gains feature parity with Avahi (most notably the publishing parts that 
are used by 3rd party software).
Or the maintenance status of Avahi changes in a bad way.



In summary: Building systemd with "-Ddefault-mdns=no" will result in 
systemd-resolved shipping a /etc/systemd/resolved.conf containing 
"MulticastDNS=no".

This can be easily overridden by an explicit drop-in snippet, say 
/etc/systemd/resolved.conf.d/mdns.conf, containing "MulticastDNS=yes".
Explicit configuration is needed on a per-link basis anyway.

This is a configuration which is consistent with other major 
distributions like Fedora or Ubuntu.

The CTTE decision should be (time) limited but not for trixie alone.
It should take into account changes in resolved and Avahi.


Regards,
Michael





[0] https://github.com/avahi/avahi
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077937#71
[2] 
https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#MulticastDNS=
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077937#46
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20250211/174b5d17/attachment.sig>


More information about the Pkg-systemd-maintainers mailing list