systemd/resolved can't enable mdns permanently

[Hadmut Danisch]

I currently ran into the problem, that systemd (i.e. its resolved) cannot properly configured to run with mdns.

I'm currently setting up some machines in a network with a poor router which routes and offers DHCP, but does not put the DHCP clients into a DNS domain, so the machines need to use mdns to find each other.

In order to have systemd/resolved use mdns, two steps are necessary:

1. MulticastDNS=yes must be put into /etc/systemd/resolved.conf and resolved restarted to enable it in general.

2. It must be enabled per interface. On the command line this can be done with
resolvectl mdns eth0 yes

result:
# resolvectl mdns
Global: yes
Link 63 (eth0): yes

and it works.

Problem: It cannot be done automatically in a server/LXD image. Im having this problem inside the LXD 22.04 image.

a) man pages suggest that /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
MulticastDNS=yes

would do the job, but it doesn't. It seems to be completely ignored.

The reason seems to be that
networkctl status eth0
shows

                  Network File: /run/systemd/network/10-netplan-eth0.network

so it seems to be overridden by netplan.

b) netplan itself does not seem to support the MulticastDNS settings.

c) On Desktop Machines I found a workaround with NetworkManager, but on server and LXD images, Network Manager does not exist.

So I do not see a way to have this configured permanently (other than writing a systemd unit).

But:

I need to configure the machines / LXD machines using cloud-init, in order to have the installation pull packages from a server to be found with mdns.

I tried to run
resolvectl mdns eth0 yes

as a bootcmd in Cloud-init, but this has no effect, because it is too early.

I tried to run it as a runcmd, and it works but it is too late, because package installation has already failed.

So where in this scrub between systemd and netplan could mdns be enabled in a way, that the automatic installation would work?

[Nick Rosbrook (enr0n)]

You can use a drop-in configuration to achieve this:

$ cat /etc/systemd/network/10-netplan-eth0.network.d/mdns.conf
[Match]
Name=eth0

[Network]
MulticastDNS=yes

This will basically append the MulticastDNS option to the existing netplan-generated network configuration. Does that solve your problem?

[Hadmut Danisch (hadmut)]

I'm currently away from this particular network for some time, I'm currently jumping between different countries.

If this just merges these settings into the systemd file generated by netplan without the need of netplan to be able to deal with mdns, this should do the job.

But I wasn't aware that there is this way of appending settings by opening a .d/ directory and putting additional settings in it.

However, it doesn't seem to work.

I just tested this on a different machine (22.04 server) in a different network, where mdns is usually not used.

I've enabled mdns on /etc/systemd/resolv.conf,

resolvectl mdns
Global: yes
Link 2 (enp1s0): no
Link 3 (eno1): no

the default interface connected to the lan is eno1.

Therefore, I created
/etc/systemd/network/10-netplan-eno1.network.d/mdns.conf

with

[Match]
Name=eno1

[Network]
MulticastDNS=yes

and rebootet the machine.

But mdns still not enabled for this network.

# networkctl status eno1
● 3: eno1
                     Link File: /run/systemd/network/10-netplan-eno1.link
                  Network File: /run/systemd/network/10-netplan-eno1.network
                          Type: ether
...

 and /run/systemd/network/10-netplan-eno1.network

[Match]
Name=eno1

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6

[DHCP]
RouteMetric=100
UseMTU=true

So no, the MulticastDNS setting doesn't make its way into the config from this way of setting.

[Nick Rosbrook (enr0n)]

The option doesn't literally get appended to the original file, but when the settings are applied it will use the drop-in conf as well. What does resolvectl mdns show? The rest of your output looks expected (networkctl status won't mention the use of the drop-in config). I have tested this on 22.04 server and it works, so please double check everything.

[Hadmut Danisch (hadmut)]

It shows

# resolvectl mdns
Global: yes
Link 2 (enp1s0): no
Link 3 (eno1): no
Link 4 (lan): no
Link 5 (finnland): no
Link 6 (docker0): no
Link 8 (veth21cf34c5): no

In other words: No.

[Nick Rosbrook (enr0n)]

Are there any errors in your journal about the config? Check journalctl -b 0 --grep eno1 for starters. Also just to double check, you are running the latest version of systemd in jammy, right? It should be 249.11-0ubuntu3.6.

[Hadmut Danisch (hadmut)]

# journalctl -b 0 --grep eno1 | cut -c22-
 kernel: igb 0000:02:00.0 eno1: renamed from eth1
 systemd-networkd[763]: eno1: Link UP
 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
 systemd-networkd[763]: eno1: Gained carrier
 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
 avahi-daemon[742]: Joining mDNS multicast group on interface eno1.IPv6 with address fe80::201:c0ff:fe21:3400.
 avahi-daemon[742]: New relevant interface eno1.IPv6 for mDNS.
 systemd-networkd[763]: eno1: Gained IPv6LL
 avahi-daemon[742]: Registering new address record for fe80::... on eno1.*.
 avahi-daemon[742]: Leaving mDNS multicast group on interface eno1.IPv6 with address fe80::....
 avahi-daemon[742]: Joining mDNS multicast group on interface eno1.IPv6 with address 2a02:....
 avahi-daemon[742]: Registering new address record for 2a02:... on eno1.*.
 avahi-daemon[742]: Withdrawing address record for fe80::... on eno1.
 avahi-daemon[742]: Registering new address record for fdfc:... on eno1.*.
 systemd-networkd[763]: eno1: DHCPv4 address 192.168..../24 via 192.168....
 avahi-daemon[742]: Joining mDNS multicast group on interface eno1.IPv4 with address 192.168.....
 avahi-daemon[742]: New relevant interface eno1.IPv4 for mDNS.
 avahi-daemon[742]: Registering new address record for 192.168.... on eno1.IPv4.
 systemd-networkd-wait-online[809]: managing: eno1

# resolvectl mdns
Global: yes
Link 2 (enp1s0): no
Link 3 (eno1): no
...

[Launchpad Janitor (janitor)]

[Expired for systemd (Ubuntu) because there has been no activity for 60 days.]