Find your systems easily on a LAN with mDNS

Multicast DNS, or mDNS, lets systems broadcast queries on a local network to find other resources by name. Fedora users often own multiple Linux systems on a router without sophisticated name services. In that case, mDNS lets you talk to your multiple systems by name — without touching the router in most cases. You also don’t have to keep files like /etc/hosts in sync on all the local systems. This article shows you how to set it up.

mDNS is a zero-configuration networking service that’s been around for quite a while. Fedora ships Avahi, a zero-configuration stack that includes mDNS, as part of Workstation. (mDNS is also part of Bonjour, found on Mac OS.)

This article assumes you have two systems running supported versions of Fedora (27 or 28). Their host names are meant to be castor and pollux.

Installing packages

Make sure the nss-mdns and avahi packages are installed on your system. You might have a different version, which is fine:

$ rpm -q nss-mdns avahi
nss-mdns-0.14.1-1.fc28.x86_64
avahi-0.7-13.fc28.x86_64

Fedora Workstation provides both of these packages by default. If not present, install them:

$ sudo dnf install nss-mdns avahi

Make sure the avahi-daemon.service unit is enabled and running. Again, this is the default on Fedora Workstation.

$ sudo systemctl enable --now avahi-daemon.service

Although optional, you might also want to install the avahi-tools package. This package includes a number of handy utilities for checking how well the zero-configuration services on your system are working. Use this sudo command:

$ sudo dnf install avahi-tools

The /etc/nsswitch.conf file controls which services your system uses to resolve services, and in what order. You should see a line like this in that file:

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

Notice the commands mdns4_minimal [NOTFOUND=return]. They tell your system to use the multicast DNS resolver to resolve a hostname to an IP address. Even if that service works, the remaining services are tried if the name doesn’t resolve.

If you don’t see a configuration similar to this, you can edit it (as the root user). However, the nss-mdns package handles this for you. Remove and reinstall that package to fix the file, if you’re uncomfortable editing it yourself.

Follow the steps above for both systems.

Setting host name and testing

Now that you’ve done the common configuration work, set up each host’s name in one of these ways:

  1. If you’re using Fedora Workstation, you can use this procedure.
  2. If not, use hostnamectl to do the honors. Do this for the first box:
    $ hostnamectl set-hostname castor
  3. You can also edit the /etc/avahi/avahi-daemon.conf file, remove the comment on the host-name setting line, and set the name there. By default, though, Avahi uses the system provided host name, so you shouldn’t need this method.

Next, restart the Avahi daemon so it picks up changes:

$ sudo systemctl restart avahi-daemon.service

Then set your other box properly:

$ hostnamectl set-hostname pollux
$ sudo systemctl restart avahi-daemon.service

As long as your network router is not disallowing mDNS traffic, you should now be able to login to castor and ping the other box. You should use the default .local domain name so resolution works correctly:

$ ping pollux.local
PING pollux.local (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1 (192.168.0.1): icmp_seq=1 ttl=64 time=3.17 ms
64 bytes from 192.168.0.1 (192.168.0.1): icmp_seq=2 ttl=64 time=1.24 ms
...

The same trick should also work from pollux if you ping castor.local. It’s much more convenient now to access your systems around the network!

Moreover, don’t be surprised if your router advertises services. Modern WiFi and wired routers often provide these services to make life easier for consumers.

This process works for most systems. However, if you run into trouble, use avahi-browse and other tools from the avahi-tools package to see what services are available.

Fedora Project community Using Software

13 Comments

  1. Edgar Hoch

    You mention that package nss-mdns modifies /etc/nsswitch.conf in scriptlets. Yes, it does, and this is the problem: It conflicts with authselect on Fedora 28, because no other program than authselect should modify /etc/nsswitch.conf. See https://bugzilla.redhat.com/show_bug.cgi?id=1577243 .

    • @Edgar: It could equally be said that authselect’s expectation that only it ever touches nsswitch.conf, without reasonable facilities for handling more situations required by modern users, is also the problem. Apparently the upstreams are sorting the situation out, and I look forward to amending this article if/when that happens.

      • Edgar Hoch

        Paul, yes, I agree. The change from authconfig to authselect in Fedora 28 was to early, authselect is still not ready for all situations, there should be tools to modify configuration files but only to create a complete new profile. I had to do this for nis, because the developers had decided that only sssd and winbind will be neccessary. But sssd doen’t work well with nis. And I did need nscd, because Fedora 28 had decided to set IPAddressDeny=any in systemd-logind.service. Now they have changed there mind and nss_nis adds a file that set IPAddressAllow=any.

        I am already following upstream authselect at github. They have created a nis profile, that’s fine. I am not sure if adding file user-nsswitch.conf is a good solution for the problem. But we man see…

        Another note: Is it intended that you set hostname in your example to a name without a domain? Shouldn’t it contain at least .localdomain? I think that some programs may have problems (e.g. sendmail may delay startup).

        • @Edgar: Indeed, some users may need to name their box e.g. “castor.localdomain” if they’re using certain other services. That’s not often the case for home network users, but it’s a very good point nonetheless — thanks.

  2. I have been using Fedora 27 for a long time and I am quite happy. Is there any reason for the update?

    Thanks in advance!

    Kindest regards,
    Slavisa

  3. vortex

    avahi is great, except it is unfortunate that it has never properly supported DNS-SD in that registrations over mdns can be reflected in unicast dynamic DNS, unlike the macos equivalent mDNSresponder (or the posix version).

  4. Andreas WERNER

    Are there more infos about using mDNS?

    What happens if there are more than one mDNS services/servers are running in a LAN? Are they concurrent?

    I have a prof audio device from MOTU which is also using mDNS.

    How to see all the MDNS systems running in a LAN? And all *.local domain names announced?

    Best regards
    Andreas WERNER

    • @Andreas: While I’m not an expert at mDNS, the way the service is designed is that each system that implements it advertises itself. No central server is used or expected, and all the services on the LAN are expected to coexist. The .local domain is the default domain for mDNS so it’s expected that services would support it. Check your unit’s manufacturer documentation or website for more information on their implementation if you don’t see expected results.

  5. RG

    There are firewalls that block mDNS traffic. E.g. Freifunk in Germany does such kind because it heavily increases needed bandwith. For home or a virtual environment, mDNS is great.

    • vortex

      Hi RG,

      mDNS consists of a multicast packet transmitted with a TTL of one, it never leaves your local network segment unless specific multicast routing is present on the LAN.

      Cheers.

  6. That’s not often the case for home network users, but it’s a very good point nonetheless — thanks.I have been using Fedora 27 for a long time and I am quite happy.

  7. dag

    Might seem obvious but if you’re trying to setup dual stack ipv4/6 make sure you change the setting from mdns4_minimal to mdns_minimal so that ipv6 addresses are also resolved.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions