How to Implement mDNS Service Discovery Across VLANs
Why mDNS Stops at VLAN Boundaries
Multicast DNS (mDNS) operates by sending queries and announcements to the link-local multicast address 224.0.0.251 on UDP port 5353. By design, routers do not forward link-local multicast traffic between subnets. This is intentional — it limits broadcast storms — but it creates a hard wall that prevents mDNS across VLANs from working natively.
In a segmented enterprise or home-lab environment, a printer on VLAN 20 is completely invisible to a workstation on VLAN 10. Apple Bonjour services, AirPlay, Chromecast, HomeKit, and countless IoT devices all rely on mDNS for zero-configuration discovery, so this limitation has real operational impact.
Understanding the mDNS Protocol Stack
Before implementing a cross-VLAN solution, it helps to understand exactly what mDNS does. When a device wants to discover services — say, a _ipp._tcp.local printer — it sends a DNS query to 224.0.0.251:5353. Devices that offer that service respond directly on the same multicast group. There is no central DNS server involved.
Service records follow standard DNS resource record formats: PTR records advertise service types, SRV records provide hostnames and ports, and TXT records carry metadata. A complete mDNS implementation must relay all three record types to make cross-VLAN discovery fully functional, not just forward raw packets.
Option 1: mDNS Proxy (Recommended for Enterprise)
An mDNS proxy listens on multiple VLANs, caches service records from each segment, and responds to queries on behalf of devices in other segments. The proxy is a unicast intermediary — it never forwards raw multicast packets, which keeps the solution clean and scalable.
Cisco IOS devices running 15.2(1)T or later support the ip mdns-sd feature set. On a Layer 3 switch or router with sub-interfaces for each VLAN, the configuration looks like this:
ip mdns-sd gateway
!
interface Vlan10
ip mdns-sd gateway
!
interface Vlan20
ip mdns-sd gatewayAvahi, the open-source mDNS daemon common on Linux, can act as a proxy when configured with enable-reflector=yes in /etc/avahi/avahi-daemon.conf. However, Avahi's reflector mode floods multicast to all interfaces rather than acting as a true proxy, which can cause issues at scale.
For a production-grade open-source alternative, mdns-repeater and avahi-daemon with careful interface binding are common choices. On pfSense and OPNsense, the built-in Avahi package provides a GUI-driven mDNS proxy that bridges selected interfaces without requiring command-line configuration.
Option 2: mDNS Repeater for Simpler Topologies
An mDNS repeater is simpler than a proxy: it receives a multicast packet on one interface and retransmits it on other configured interfaces. There is no caching or record inspection. This approach works well in smaller environments where you have two or three VLANs and low mDNS traffic volume.
The mdns-repeater daemon on Linux accepts a list of interface names as arguments:
mdns-repeater eth0.10 eth0.20 eth0.30The trade-off is that repeaters can amplify traffic in large environments and do not handle TTL-scoped queries intelligently. For networks with more than five VLANs or heavy IoT deployments, a proper proxy is the better investment.
Handling mDNS Across VLANs on Ubiquiti UniFi
UniFi controllers include a built-in mDNS repeater under Settings → Services → mDNS. Enabling it allows mDNS traffic to cross between the default LAN and IoT networks automatically. For custom VLAN topologies, you must ensure the UniFi Security Gateway or Dream Machine has Layer 3 interfaces on each VLAN and that the mDNS service is enabled globally.
One important caveat: UniFi's implementation does not support service filtering. All mDNS records from all VLANs are shared with all other VLANs. If your security policy requires restricting which services are visible across segments, you will need a third-party proxy with ACL support, such as the one built into Cisco IOS-XE.
Firewall Rules and Security Considerations
Forwarding mDNS across VLANs introduces a controlled security relaxation. Devices in one segment become discoverable from another. Ensure your inter-VLAN firewall rules allow UDP port 5353 from the proxy's IP address specifically, not from all hosts. Block direct multicast forwarding at the VLAN interface level to prevent bypass.
For IoT-heavy environments, consider a one-way proxy configuration where IoT devices on VLAN 30 are discoverable from VLAN 10, but VLAN 10 devices are not advertised back into VLAN 30. This limits the attack surface while preserving usability.
Testing and Verifying Cross-VLAN Discovery
After deploying your proxy or repeater, validate the setup using dns-sd on macOS or avahi-browse on Linux from a client on a different VLAN than the service:
# macOS
dns-sd -B _services._dns-sd._udp local
# Linux
avahi-browse -a -tIf services appear in the output, mDNS across VLANs is functioning correctly. If not, use tcpdump -i eth0.20 udp port 5353 on the proxy host to verify packets are arriving and being processed. Confirm that the proxy's network interfaces are all assigned to the correct VLANs and that no firewall rule is silently dropping the relayed traffic.