Ambiguity in mdns configuration

[Hadmut Danisch]

Hi,

I recently failed to get a 22.04 and 23.04 running reliably in a network with a cheap Huawei fiber router which provides routing and DHCP, but does not offer a DNS service with a zone with DHCP hosts. Therefore, machines cannot find each other by DNS.

Since mdns is designed to solve this problem (and I could remember that Ubuntu was dealing with such networks properly about 10 years ago), I tried to configure the machines to use mdns.

I was not able to get things running, since there are collisions between systemd/resolved on one hand, and avahi daemon on the other, colliding both on the UDP port and the functionality.

systemd/resolved are not really able to provide all services, but it is not possible to use avahi only either, since systemd/resolved is built so deeply into ubuntu, that it can't be removed or turned off without breaking lots of functionalities. Furthermore, I found systemd to be unreliable as an mdns resolver. Sometimes it works, sometimes it doesn't, sometimes it takes minutes.

I would have expected that Ubuntu would drop avahi daemon after moving to systemd, but now I found that 24.04 still comes with avahi daemon and competing functionalities.

E.g. avahi suggests to install libnss-mdns, while resolved wants mdns to be enabled in /etc/systemd/resolved.conf and to handle it itself.

So what is the suggested way to use Ubuntu in a network without proper DNS for DHCP-clients?

systemd+resolved? avahi? both?

I did not find any documentation about this, no simple configuration settings, no answer to the question how mdns should be used on Ubuntu since Ubuntu moved to systemd.

Nobody seems to care.

regards

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Libera.chat.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/2062927/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Nick Townsend (townsen)]

This report raises an important question about the defaults and setup for systemd-resolved. This was first raised in the following post a year ago: https://lists.ubuntu.com/archives/ubuntu-devel/2023-March/042499.html but as far as I can see remains unresolved.

This is an important issue for many and some clarity is required, perhaps Lukas Märdian could update us? slyon @ ubuntu.com

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Trent Lloyd (lathiat)]

It's not possible to correctly run two mDNS stacks at the same time, as while multicast udp packets can be received by multiple programs, only one program will receive unicasted port 5353 mDNS replies, even if both daemons allow multiple-binding to port 5353.

While actually using that feature is not so commonly used intentionally, it is used sortof by accident by many enterprise wireless network vendors when they "convert" multicast to unicast as a network optimisation (because multicast packets are truly multicasted, but at a "base" network rate much slower than the normal rate of the clients, which uses up more airtime than sending them all individually at a higher speed).

Hence, we cannot really enable the independent systemd-resolved support at the same time as actually using Avahi to do proper service discovery, and you should use the avahi/nss-mdns support instead if you want any actual mDNS service discovery support.

Ideally resolved would add a backend to use avahi when it exists/is installed so we could drop the extra nss-mdns step. But no one has written that code so far.

But I am not sure why you say you cannot disable the systemd-resolved mDNS support. It's disabled in resolved by default out of the box, and then when disabled it doesn't bind to the port, so Avahi works fine, and nss-mdns will work find alongside systemd-resolved. Many people use this configuration all the time.

So I am curious.. in what specific scenario and configuration are you seeing it enabled and the port conflict?

On an out of the box install if you run "resolvectl status" you'll see -mDNS on all the interfaces. Can you detail your configuration more precisely?

[Hadmut Danisch (hadmut)]

Well, the problems I had happened about 1.5 years ago with Ubuntu 22.04 and a Huawei fiber router with DHCP, but without local DNS zone, and I recall all details, just the fact that only Ubuntu machines had problems, while other Linux-based machines didn't, and after several days of working I just gave up and bought an OpenWRT router to put between just to get Ubuntu machines running.

As far as I remember the main problem was, that I usually put my clients and services in LXD, docker and podman containers, and I was not able to get mdns running within these containers since they do not receive those mdns packages. I found no way to redistribute them into all containers, and one of the problem is that the containers do have IP addresses from different ranges.

Another problem was that container machines like LXD and docker enforce to either forward DNS requests to either 127.0.0.53:53 (=resolved) or the router (=Huawei fiber), but there is no DNS service to forward mDNS requests to.

I got some success by not telling the machines in the container anything at all about mdns, just let them forward all requests, including to the .local. domain, to the container mechanism, i.e. to resolved runnin g on the host. This works for querying, but is highly unreliable. Sometimes it took more than 10 Minutes to finally resolve a machine. resolved's mdns implementation seems somewhat broken and to suffer from some bugs.

The other problem is that resolved does not advertise anything other than its own host name.

So this runs into two contradicting requirements:

1. To resolve mdns queries from within a container, you need to ignore mdns inside the container and let the container environment do the job, i.e. forward to resolved (which mdns settings enabled).

2. To advertise services or virtual machines (such as the containers), you need avahi, because resolved can't. Resolved just performs very simple client tasks, even those unreliably.

But not both resolved and avahid can have the mdns, and you can't tell resolved to use mdns, but not to occupy the port.

I do remember that I had used mdns with Ubuntu around 2007, and it was working perfectly then.

Now the problem seems to be, that on one hand systemd+resolved is enforced and so deeply implanted, that you can't avoid it and container environments like LXD, docker enforce to forward DNS queries from within the container to the hosts's resolved, but resolved's implementation is incomplete and broken.

Actual example: I usually have a virtual machine running on LXD called "install", which offers services like a puppet server, docker cache, debian/ubuntu cache, gem server. I'm using this method for years. But I simply was not able to get this running and to install LXD containers on other machines in a network managed by this Huawei router with DHCP, but without a DNS zone reflecting DHCP assignments. I would have had to assign all IP addresses statically and enter them in to /etc/hosts.

I ended up with buying an additional router with proper DNS, just to get the Ubuntu machines up and running, since the cannot properly deal with mdns.

I had hoped that things were getting better with ...