resolved.conf file and set the mdns=resolve option within the [Resolve] section. After saving the changes, restart the systemd-resolved service to apply the new settings immediately without needing a full system reboot.
Understanding systemd-resolved and Multicast DNS
When replacing traditional networking stacks like NetworkManager or avahi-daemon with a minimal setup relying on systemd-resolved, it is crucial to understand how name resolution is handled locally. Multicast DNS (mDNS) allows devices on a local network to discover each other using names ending in .local without a central DNS server. While systemd-resolved is powerful for managing standard DNS zones and stub resolvers, it treats mDNS as an optional capability rather than a core function.
The daemon includes built-in support for both resolving and answering mDNS queries, but this functionality is turned off out of the box to prevent conflicts with other services or unnecessary network traffic. If you have removed avahi-daemon and expect your system to respond to ping myhostname.local from other machines, you must explicitly configure systemd-resolved to take over this role. This approach simplifies the service landscape by removing redundant daemons, provided the configuration is correct.
Configuring the resolved.conf File
The primary configuration file for the resolver is located at /etc/systemd/resolved.conf. You will need root privileges to modify this file. Open the file using your preferred text editor, such as nano or vim.
sudo nano /etc/systemd/resolved.confLocate the [Resolve] section near the top of the file. You may see comments explaining various options, but the specific line for mDNS might be commented out or missing entirely. Add or modify the following line:
[Resolve]
mdns=resolveThe value resolve instructs the daemon to query the local link for mDNS records when a standard DNS lookup fails. If you also want your system to advertise its own hostname via mDNS so other devices can find it, you should use mdns=yes instead. The yes setting enables both resolving incoming queries and answering outgoing advertisements. For most cases where you simply want your machine to be discoverable, mdns=yes is the appropriate choice.
Distinguishing Between Resolve and Yes
It is important to distinguish between the two main modes available in the configuration. Setting mdns=resolve makes systemd-resolved act as a client that looks up .local addresses. It does not make the host itself respond to queries about its own name. Conversely, mdns=yes activates the server component, allowing the machine to announce its presence on the network. If your goal is to replace avahi-daemon completely, you likely need mdns=yes.
Applying Changes and Verifying Status
Once you have saved the configuration file, you must restart the systemd-resolved service for the changes to take effect. Unlike some configurations that require a reboot, this change is dynamic.
sudo systemctl restart systemd-resolvedAfter restarting, verify that the service has loaded the new configuration by checking its status. You can use the resolvectl command to inspect the current state of the resolver.
resolvectl statusLook for the mDNS column in the output. It should indicate that mDNS is enabled for the relevant network interfaces. If you are unsure which interface is active, check the output for the interface associated with your current network connection. Additionally, you can test if your system is responding to mDNS queries by running a ping command from another device on the same subnet:
ping -c 4 your-hostname.localIf the ping succeeds, the configuration is working correctly. If it fails, ensure that your firewall settings are not blocking UDP port 5353, which is used by mDNS traffic.
Troubleshooting Common Issues
Even with correct configuration, several factors can prevent mDNS from functioning as expected. First, verify that the network interface itself supports multicast. Some virtualized environments or restricted container setups may drop multicast packets unless explicitly configured otherwise.
Second, check for conflicts with other local name resolution services. Although you mentioned removing avahi-daemon, ensure that no residual configuration files remain in /etc/hosts or other resolver directories that might interfere. The systemd-resolved service uses a search domain list, and ensuring that .local is included in the Domains field in resolved.conf can sometimes help prioritize local lookups.
Finally, consider the scope of the mDNS queries. By default, mDNS operates only on the local link. If you are trying to resolve names across subnets, standard unicast DNS is required, as mDNS does not route beyond the immediate network segment. This limitation is inherent to the protocol and not a configuration error.
Frequently Asked Questions
Can I use mdns=yes and still use standard DNS servers?
Yes, enabling mDNS does not disable standard DNS resolution. The systemd-resolved daemon handles both protocols simultaneously. Standard DNS queries go to the servers listed in the DNS field, while mDNS queries are handled locally on the link. You can safely combine these settings without conflict.
Why is my hostname not appearing on the network after enabling mDNS?
Ensure that you set mdns=yes rather than just mdns=resolve. The resolve option only allows the system to look up other hosts, while yes enables the system to advertise its own hostname. Also, verify that the hostname itself is valid and does not contain special characters that might break mDNS registration.
Does systemd-resolved support mDNS for IPv6?
Yes, systemd-resolved supports Multicast DNS over IPv6 (mDNSv6). The configuration option mdns applies to both IPv4 and IPv6 interfaces automatically. As long as your network stack has IPv6 enabled and properly configured, the resolver will handle mDNS queries on both protocols.
What happens if I remove avahi-daemon but don't configure systemd-resolved?
If you remove avahi-daemon without configuring systemd-resolved for mDNS, your system will stop advertising its hostname and will no longer be able to resolve .local names from other devices. This results in a loss of local discovery capabilities, which may break applications that rely on zero-configuration networking.
How do I check which interfaces have mDNS enabled?
You can use the resolvectl mdns command to list all network interfaces and their mDNS status. This command provides a clear view of whether mDNS is enabled, disabled, or set to resolve mode for each specific interface, helping you troubleshoot connectivity issues on multi-homed systems.