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

[Helmut Grohne]

Hi Sam and others,

thanks for shifting the perspective.

On Thu, Jan 16, 2025 at 09:49:41AM -0700, Sam Hartman wrote:
> It also seems like the TC has the option of providing policy here, for
> example policy on what the default MDNS implementation is in Debian or
> policy on  how services can interact that gives guidance on the
> interaction between packages like avahi-daemon and systemd-resolved.

I'm not sure how such policy would help resolve the conflict. Given
reverse dependencies of popular packages, avahi-daemon is the de-facto
default implementation, but does that preclude resolved from performing
resolving in the absence of avahi-daemon (as requested by Luca)?

Other packages have two main mechanisms to interact with mDNS
implementations. They may resolve (works with either in principle) and
they may publish (each has their own format and location here). We
cannot reasonably ask either to adopt the other's format.

Would you have an idea of what kind of policy could be enacted and how
it would help resolve the conflict?

> For what it's worth, as someone who is not involved in the TC, I
> definitely think our users would be best solved by resolving things so
> that a default desktop installation of Debian has avahi-daemon as a
> working mdns resolver without systemd-resolved getting in the  way.

If you install a desktop environment, it will presently install
avahi-daemon. task-desktop Recommends libnss-mdns which in turn
Recommends avahi-daemon. From what I have read, we all (including Luca)
agree that this is what we want.

That "without systemd-resolved getting in the way" part is more subtle.
We saw that Fedora opted for disabling resolution in resolved and not
just publishing as originally intended. A kind soul (thanks) pointed me
at the reason for that. If resolved is acting as a resolver, it is
presently listed first and does not return to other resolvers, so avahi
won't get a pass if resolved has resolution enabled.
https://bugzilla.redhat.com/show_bug.cgi?id=1867830

As a result, I am now convinced that the problem is not just that having
resolved and avahi do concurrent publishing is a problem, but also
having both enabled as resolvers is a problem. I expect others to agree
given the evidence and think this rules out options where resolved
defaults to resolving only or where avahi-daemon disables only the
publishing functionality in resolved. Practically this reduces our
choice to "resolved has mDNS disabled by default" vs "avahi-daemon
disables mDNS in resolved".

Given that it was mentioned often enough, having a resolution reaffirm
that avahi-daemon should be the default in either case seems fine to me.
As such I now see the following possible ballot options:

(S) The CTTE reaffirms that avahi-daemon is the default mDNS
    implementation in Debian trixie. Therefore systemd-resolved should
    disable the mDNS functionality in its default installation in Debian
    trixie.
    (Requires a 3:1 majority overruling a developer.)

(A) The CTTE reaffirms that avahi-daemon is the default mDNS
    implementation in Debian trixie. This does not preclude other
    resolvers such as systemd-resolved operating when avahi-daemon is
    not installed. To achieve this, avahi-daemon should disable
    systemd-resolved using a resolved configuration file.
    (Requires a 3:1 majority overruling a developer.)

(F) Further discussion

The main changes here are reaffirming the default implementation and
discarding the options where resolution is enabled in both
implementations on the grounds that resolved would be preferred where
avahi-daemon should be preferred.

In principle, we could also reconfigure nsswitch.conf to prefer
avahi-daemon over resolved. I am not putting this up as an option yet as
there is no proposal nor patch for this.

Does anyone see nuances of the matter that have not yet been explored?
My impression is that whilst Luca opted for not participating he
expressed relatable reasons earlier and Michael clarified his reasons
during the discussion.

Helmut