Support "wide-area" DNS-SD lookups

[dwagenk]

Hello!

I'm stuck during setup of printer discovery via unicast DNS-SD. I think this is termed "Wide Area Bonjour" in some contexts. I assumed cups would query avahi for print services on the network regardless whether they are announced via unicast DNS-SD or multicast DNS-SD. But cups only finds the multicast DNS-SD (.local) printers, while e.g. the avahi-discover gui tool lists the .local domain as well as the services from configured browsing domains.

I think cups should also query unicast DNS-SD for all configured browsing domains or at least the default browsing domain. This would allow network admins to configure printers in the domain via the DNS server without relying on mDNS (which doesn't cross subnets).

From the avahi docs:

All applications that offer the user a list of services discovered with Avahi should offer some kind of editable drop down box where the user can either enter his own domain or select one of those offered by AvahiDomainBrowser. The default domain to browse should be the one returned by avahi_client_get_domain_name().

File managers offering some kind of "Network Neighborhood" folder should show the entries of the default domain right inside that and offer subfolders for the browsing domains returned by AvahiDomainBrowser.

For the default search domain I'd interpret this as "show it". For additional search domains It's a little unclear whether they should be shown or ommitted. I think I'd default to showing them as well.

The dnssd backend (using avahi) code passes domain=NULL to the avahi_service_browser_new function e.g. here which queries only the multicast .local(or whatever is configured in avahi-daemon.conf as domain-name) domain.

The service query would need to be repeated for all domains returned by the avahi_domain_browser_new function (avahi docs).

I tried discovering printers by running /usr/lib/cups/backend/dnssd standalone on different cups versions and linux distros (NixOS: cups 2.3.3, also on up to date ManjaroARM and Ubuntu 20.04, but I don't have them at hand right now to look at the cups version).

I didn't check how the other libraries used by the dnssd backend handle this.

Let me know if I you need any more information on this. I could also prepare a PR sometime in the coming weeks.

[zdohnal]

Hi @dwagenk ,

thank you for bringing this up! Supporting unicast DNS-SD sounds neat, any PR related to it is welcome :) . It would be a good feature in addition to printer profiles (which will solely use IPP protocol).
However, AFAIK the dnssd backend's functionality is covered and enhanced now by CUPS library + IPP backend, so the dnssd backend will go away. So the new functionality should be implemented in the library (probably cups_enum_dests() function and friends, which do the queries via Avahi to get devices).
The functions could look into a file which can be located in /etc/cups or in ~/.cups, where the additional domains for discovery can be listed. WDYT?

[dwagenk]

Hello @zdohnal ,
thanks for your reply. I still have this on my agenda, just not prioritized.

CUPS library + IPP backend [..] So the new functionality should be implemented in the library

Looks like the avahi queries are similar to what I found in the dnssd backend. The lookup in

cups/cups/dest.c

Lines 3700 to 3729 in 28c6bb1

	data.browsers = 1;
	if ((ipp_ref = avahi_service_browser_new(data.client, AVAHI_IF_UNSPEC, AVAHI_PROTO_UNSPEC, "_ipp._tcp", NULL, 0, cups_dnssd_browse_cb, &data)) == NULL)
	{
	DEBUG_puts("1cups_enum_dests: Unable to create Avahi IPP browser, returning 0.");
	avahi_client_free(data.client);
	avahi_simple_poll_free(data.simple_poll);
	cupsFreeDests(data.num_dests, data.dests);
	cupsArrayDelete(data.devices);
	return (0);
	}
	# ifdef HAVE_TLS
	data.browsers ++;
	if ((ipps_ref = avahi_service_browser_new(data.client, AVAHI_IF_UNSPEC, AVAHI_PROTO_UNSPEC, "_ipps._tcp", NULL, 0, cups_dnssd_browse_cb, &data)) == NULL)
	{
	DEBUG_puts("1cups_enum_dests: Unable to create Avahi IPPS browser, returning 0.");
	avahi_service_browser_free(ipp_ref);
	avahi_client_free(data.client);
	avahi_simple_poll_free(data.simple_poll);
	cupsFreeDests(data.num_dests, data.dests);
	cupsArrayDelete(data.devices);
	return (0);
	}
	# endif /* HAVE_TLS */

needs to be prependet with the domain resolution (avahi_domain_browser_new) and then executed for each of the found domains.

The functions could look into a file which can be located in /etc/cups or in ~/.cups, where the additional domains for discovery can be listed. WDYT?

Actually I think additional domains are not needed in cups-specific configuration. Avahi already has mechanisms for specifying additional domains and picks up the ones provided via DHCP (Option 15 "Domain", Option 119 "DNS domain search list").

[dwagenk]

Also for reference: Systems using mDNSResponder should already have the desired behaviour of scanning both multicast and unicast DNS-SD due to the domain=NULL parameter being interpreted as

both the .local and the fully-qualified domain name for the system

according to apple/cups#5071 (comment)

[MadByteDE]

Also, to comment as someone who is more on a end user level:
In my experience using Linux distros, most of them don't support .local domains in their default configuration, which makes the process of setting up printers that only have IPP / driverless filters (such as my Canon TR7550) very painful and confusing. Especially because the unknowing user can find the desired printer shown in the found printers list, can "install" it with CUPS and see it in the system, but when trying to use said printer, CUPS seems to process everything correctly (message "Rendering complete" appears when trying to print) but nothing actually prints.. Finding out the issue with .local domains and fixing it by replacing CANON-TR7550.local with the actual ip adress in the ipp:// URI of the printer took me a couple hours which could have been avoid. 😄

[zdohnal]

@MadByteDE depends on circumstances - there was a bug in CUPS 2.4.1 which was preventing using .local when you were about to use driverless queue - this should be fixed in 2.4.2, although there is a small delay between the queue is created and really working as driverless (see #347). So the reason why you couldn't use .local address could be that bug in CUPS.
Otherwise resolving .local addresses is done by nss-mdns package in distros. Or by systemd-resolved can be used for only resolving as well - it seems to cooperate with Avahi when you set resolved only for .local address resolving, and adjust your connection in NetworkManager to resolve .local address.
In Fedora I set nss-mdns as weak dependency of CUPS (because it is the least pain for user to set, though a little dangerous - you resolve every .local address on every network you connect to...), so .local resolving should work out of the box, and RHEL and its derivations have nss-mdns in EPEL repository. Probably Debian/Ubuntu brings nss-mdns as well and I'm not sure about other distros, but .local address resolving is supposed to work on every distro nowadays.

[zdohnal]

Adding links from #411, which looks like duplicate of this issue - dns-sd pages , dns-sd rfc.

[michaelrsweet]

Needs testing, but first cut is here:

[master bed9057] Initial support for multiple DNS-SD domains and Avahi.

[michaelrsweet]

Applied some additional fixes...