Date: Tue, 24 Feb 2026 15:49:05 +0000 From: bugzilla-noreply@freebsd.org To: doc@FreeBSD.org Subject: [Bug 293430] handbook: Sec 32.7 should describe how to configure mDNS and basic LAN visibility Message-ID: <bug-293430-9@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293430 Bug ID: 293430 Summary: handbook: Sec 32.7 should describe how to configure mDNS and basic LAN visibility Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: Books & Articles Assignee: doc@FreeBSD.org Reporter: bms@FreeBSD.org Following https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293425, Sec. 32.7. Domain Name System (DNS) of the FreeBSD Handbook should explain to end-users how to make FreeBSD systems visible on the network via mDNS, for feature parity with other desktop and server distributions, including Windows 11. At the moment, there are only basic instructions for installing Avahi to provide mDNS service, and nothing more. This is following https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293406, where I used a 3rd party contribution to set up FreeBSD to advertise itself on a LAN using mDNS, by registering "workstation" records via the dns-sd comman -- modulo certain security concerns with the original contributor's approach. I can confirm that works on my home LAN with a mixture of Windows 11 and Linux peers. There now follows a dump from my personal notes from last month: The least bad option sounds like the Apple-originated net/mDNSResponder and net/mDNSResponder_nss combo. NOTE: There are outdated pages about mDNS on the FreeBSD wiki. Really, this should be in base by now, but there are all sorts of Linux compat reasons for why it isn't (and of course Avahi conflicts with the Apple mDNS implementation). Good, we're now in a position to get mDNS up and running, so Windows boxen can see the FreeBSD VM on the LAN. sudo pkg install mDNSResponder sudo pkg install mDNSResponder_nss sudo vi /etc/nsswitch.conf add: hosts: files mdns dns # May not be needed, except for advertising fixed SRV records: #sudo sysrc mdnsresponderposix_enable="YES" #sudo service mdnsresponderposix start sudo sysrc mdnsd_enable="YES" sudo service mdnsd start With that, resolution of Windows node names works on the LAN from FreeBSD: %%% bms@pin:~ % dns-sd -G v4 gun.local DATE: ---Thu 15 Jan 2026--- 18:06:23.238 ...STARTING... Timestamp A/R Flags IF Hostname Address TTL 18:06:24.668 Add 2 2 gun.local. 192.168.8.11 %%% Resolution via the nss module in ping and other tools works fine now too. But Windows boxes don't see the FreeBSD box. The queries are going out, and pin is seeing them inbound. For whatever reason, mdnsd is not responding, but it queries fine via nss. 2026-01-16: Even the last(1) command is now able to print names reverse-queried via mDNS on the local LAN segment. A good question is why mdnsd is not advertising the local hostname to begin with. Do I really need to create a SRV entry via dns-sd just to do that? See: https://github.com/krolingo/mDNSResponder_on_FreeBSD It would seem so. These examples aren't suitable for committing to ports as-is, because they aren't packaged as such, and contain embedded personal pathnames. Why doesn't the mDNSResponderPosix package, and mdnsresponderposix service in $LOCALBASE/etc/rc.d, accept a configuration file? mDNSResponderPosix requires *arguments* to advertise names. The change to introduce mDNSResponderPosix and its rc script was contained in another Bugzilla entry: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182721 There is no mention of a config file in the man page, nor does strings(1) on the binary suggest a location for it. Basically all the krolingo guy is doing in his mdns_hostname.sh script is: dns-sd -R $HOST _workstation._tcp local 9 With that, pin.local correctly resolves to an IPv4 dot-quad on the LAN by default at gun. We didn't see any query answers for the link-local address, even though ifconfig -a shows it was assigned. It even works from the Hyper-V host side. I'll import the rc.d script locally and shove the wrapper script under ${LOCALBASE}/libexec. Not etc and not lib, they don't belong there. sudo cp mdns_hostname.sh /usr/local/libexec sudo chmod 755 /usr/local/libexec/mdns_hostname.sh sudo cp mdns_ws /usr/local/etc/rc.d sudo chmod 755 /usr/local/etc/rc.d/mdns_ws sudo vi /usr/local/etc/rc.d/mdns_ws Correct the user-hardcoded path name to point to libexec. You can't use ${LOCALBASE} here, as it is not set; you have to expand it manually. sudo sysrc mdns_ws_enable="YES" sudo service mdns_ws start Also, this may dangerously be running as root, when it should really be running as nobody. I added that, it's a very simple and wise change; mdnsd itself is configured to run as nobody. And even chrooted into the /var/empty jail, although when I added that, it didn't work. dns-sd isn't smart enough to chroot and drop privileges after it's started. It's a source limitation. It really has to be done in dns-sd itself; it needs to see the mdnsd sockets under /var/run. Capabilities, anyone? This mDNS daemon is macOS API source level compatible, but that buys you little these days when the Linux apps all expect systemd dbus. Seems fine running as nobody. However, IPv6 addresses are still being returned, resolved, and preferred, even though that is totally broken behind Hyper-V on Wifi. This appears to be transient and inconsistent though; sometimes peers get the v4 response first, sometimes the v6 one. There doesn't be a way to tell dns-sd to NOT advertise v6. Also, the link-locals stay on the ifnet *by design*, even though the nd6 flags say otherwise. This is also a dns-sd issue; there is no way to tell it to STOP ADVERTISING BROKEN IPV6 ADDRESSES. LAN clients have no way of knowing IPv6 connectivity to the FreeBSD node is broken when they get an AAAA response. The workaround then is to pass -4 to ssh sessions, but that might not always work for other commands or tools e.g. git. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293430-9>