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 apple/cups#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 systemd/systemd#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.

[LorbusChris]

Related:

• resolved: Add ifindex=0 support for BrowseServices to browse all mDNS interfaces systemd/systemd#40133
• https://github.com/LorbusChris/resolve-avahi-compat

[cvlc12]

Is this the right place to track progress on this issue ? Is avahi still needed for DNS-SD ?

[michaelrsweet]

@cvlc12

Is this the right place to track progress on this issue ?

Yes.

Is avahi still needed for DNS-SD ?

Yes.

[LorbusChris]

Expanding on my previous comment:

The systemd PR has merged, so with the forthcoming release of v260, one will be able to:

# Browse on all available interfaces
varlinkctl call --more unix:/run/systemd/resolve/io.systemd.Resolve \
    io.systemd.Resolve.BrowseServices \
    '{"domain":"local","type":"_ipp._tcp","ifindex":0,"flags":0}'

Ideally, this mechanism could be supported natively here in this project.

Alternatively, and not requiring any code changes, one could use a shim such as https://github.com/LorbusChris/resolve-avahi-compat which provides the avahi headers but implements them using this new resolved varlink api under the hood. Such a switchover would be done at the distro level.

[michaelrsweet]

OK, so from the sounds of things the actual DNS-SD support in systemd isn't yet released (soon?), and even once it is we will need to do extensive testing to ensure the systemd implementation of mDNS, DNS-SD, and IPv4LL is sufficient to replace Avahi.