Support mDNS/DNS-SD via systemd-resolved

[quentinmit]

Is your feature request related to a problem? Please describe. Avahi is being replaced with systemd-resolved on modern distros.

Describe the solution you'd like The DNS-SD code should be updated to use systemd-resolved's DBus interface in addition to the mDNSResponder and Avahi code that is already present.

There's an old issue at https://github.com/apple/cups/issues/5452 but, since that issue was first opened, systemd-resolved now has the required discovery and advertisment APIs.

Additional context There's a great blog post at https://daenney.github.io/2021/11/14/replacing-avahi-exploring-dnssd/ that demonstrates how to use the resolved DBus API.

[zdohnal]

My two cents:

Currently we are in transition to a new architecture in OpenPrinting (including CUPS, PAPPL, printer applications), which takes our available time.

We are always open for reviewing pull requests implementing functionality. IMHO we don't get to implementing such feature by ourselves until CUPS 3.0 is implemented and released.

Actually, there are other projects using Avahi and Avahi upstream got revived recently, preparing a new release.

[michaelrsweet]

My $0.02 CAD: it isn’t clear from your report what systemd is actually implementing - the complete Avahi D-Bus API (under a new path) or an extension of the original system-resolved API. It also isn’t clean to me which distros (and what versions) have the new enough systemd to support this, etc. Historically systemd has had terrible documentation and poor standards compliance so before we jump into this we need to ensure that the combination can actually pass the Bonjour conformance tests and work on the majority of Linux distros.

That said, CUPS 2.5 and later have a proper DNS-SD API to abstract away all of these details from the dependent printing software. Whether we can support this for CUPS 2.5 or have to delay to a later 3.x release will depend on what is actually there…

[quentinmit]

My $0.02 CAD: it isn’t clear from your report what systemd is actually implementing - the complete Avahi D-Bus API (under a new path) or an extension of the original system-resolved API. It also isn’t clean to me which distros (and what versions) have the new enough systemd to support this, etc. Historically systemd has had terrible documentation and poor standards compliance so before we jump into this we need to ensure that the combination can actually pass the Bonjour conformance tests and work on the majority of Linux distros.

systemd-resolved has its own DBus API that is not very similar to Avahi's DBus API. There's an open issue at https://github.com/systemd/systemd/issues/21669 requesting that systemd provide compatibility with Avahi's API. I'm not sure what Bonjour conformance tests you're referring to; there's something on Apple's developer site, but it seems like it's also testing link-local address assignment, which isn't something that Avahi or systemd-resolve are even responsible for.

Looking at the Git repo for systemd, it appears that the DBus API for DNS-SD was first committed for systemd v236 from Dec 2017. But I'm not sure when it became fully usable, or when that hit distros.

As a sample of the API, here's the two methods that are used for service discovery:

$ dbus-send --system --print-reply --dest=org.freedesktop.resolve1 \
   /org/freedesktop/resolve1 \
   org.freedesktop.resolve1.Manager.ResolveRecord \
   int32:0 string:"_ipp._tcp.local" uint16:1 uint16:12 \
   uint64:0
# then using one of the returned service names
$ dbus-send --system --print-reply --dest=org.freedesktop.resolve1 \
   /org/freedesktop/resolve1 \
   org.freedesktop.resolve1.Manager.ResolveService \
   int32:0 string:"Printer Name" string:"_ipp._tcp" string:"local" \
   int32:2 \
   uint64:0

That said, CUPS 2.5 and later have a proper DNS-SD API to abstract away all of these details from the dependent printing software. Whether we can support this for CUPS 2.5 or have to delay to a later 3.x release will depend on what is actually there…

I saw that abstraction layer, and it looks like it ought to be able to help support a systemd-resolved backend.