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: [email protected]
Reporter: [email protected]
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.
