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

[Helmut Grohne]

Hi Michael,

On Tue, Feb 11, 2025 at 04:18:04PM +0100, Michael Biebl wrote:
> 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.

Please refer to man 5 systemd.dnssd for publishing. Unfortunately, the
way of publishing is fully incompatible with Avahi, but publishing is
supported in theory.

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

This was mentioned during the discussion, but I may have failed to
capture it this succinctly. Thank you for writing it down in clear words.

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

As much as I'd like to bind the decision to features, I doubt I am wise
enough to foresee the future sufficiently well to guard it in that way.
Would the decision also terminate in the event Fedora switches to
resolved? The trixie limit bears a risk of revisiting the decision in
roughly half a year. That feels like plenty of time in systemd's scales.
Binding it to publishing capabilities would be foolish as it would be
terminated immediately.  Precise criteria for the maintenance status of
Avahi are difficult to define. I expect that we can make a better
decision if we revisit the matter in half a year or later. If nothing
has changed by then, putting up criteria such as those you suggest is
something that feels worth exploring to me.

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

I understand your arguments, but I reach a different conclusion, because
I see writing such criteria in an objective way pretty much impossible.
How about adding some text that advises systemd maintainers to consult
with the CTTE before changing the default post trixie?

Helmut