mDNS Gateway Across VLANs: Bonjour Reflection Setup

Wireless devices, printers and Apple TVs advertise themselves with multicast DNS on 224.0.0.251:5353. Because that address is link-local and mDNS has no router across VLANs, everything works on a flat network and nothing works the moment you segment. Users then report the classic symptom: "the printer is visible on Wi-Fi but not from the office VLAN". An mDNS gateway (also called an mDNS reflector or Bonjour Gateway) solves this by proxying selected service types between VLANs. This article covers how mDNS works, what a gateway actually rewrites, how to configure one, and how to keep the multicast flood from becoming a performance problem.

Why mDNS does not route

Query target:  224.0.0.251 (IPv4) / ff02::fb (IPv6)
UDP port:      5353
TTL:           1 (never forwarded by a router)
Behaviour:     multicast query -> unicast or multicast answer

RFC 6762 defines the protocol and RFC 6763 the service discovery format. The TTL of 1 is the deliberate design choice that keeps mDNS scoped to a link, which is exactly why reflection is needed rather than routing.

What the gateway actually does

A gateway maintains a cache of service announcements learned on each VLAN. When a query arrives from VLAN A for _ipp._tcp.local, the gateway checks its cache for matches on VLAN B and answers on B's behalf, substituting its own address as the responder so the client can reach it. The service record keeps pointing at the real device, so subsequent unicast traffic goes directly to the device once routing allows it.

The practical consequence: the device's own IP must be reachable from the querying VLAN. Reflection only solves discovery, not reachability.

Typical topology

VLAN 10  Corporate Wi-Fi        clients that query
VLAN 20  Printers / IoT         devices that advertise
VLAN 30  Guest Wi-Fi            optional, usually restricted
Gateway: switch or WLC with mDNS gateway feature enabled per VLAN

Configuration pattern (wireless controller / switch)

! Cisco Catalyst 9800 (pattern; AireOS and Aruba use similar wording)
wireless mdns-sd gateway
 mdns-sd service-definition airplay
  service-type _airplay._tcp.local
 mdns-sd service-definition printing
  service-type _ipp._tcp.local
  service-type _ipps._tcp.local
 mdns-sd service-policy MDNS-POLICY
  service-definition airplay
  service-definition printing
  ! optional: restrict by direction or VLAN
mdns-sd gateway service-policy MDNS-POLICY

! verify
show wireless mdns-sd service-policy
show wireless mdns-sd gateway summary

Always restrict by service definition. A gateway configured to reflect "everything" turns every Chromecast discovery into inter-VLAN multicast and is a standard cause of wireless controller CPU spikes.

Controlling the multicast footprint

! keep IGMP snooping strict so queries only flood where needed
ip igmp snooping vlan 20
ip igmp snooping querier   ! on the L3 gateway of each VLAN
! bound the reflection rate
mdns-sd gateway rate-limit ...
! never reflect into guest VLANs unless the service is deliberately public

Snooping matters because without a querier, IGMP snooping can time out its group memberships in VLANs that have no L3 gateway sending general queries. See IGMP snooping and PIM multicast configuration for the general Multicast design.

IPv6 and other limitations

mDNS exists in parallel over IPv6 (ff02::fb). If both stacks are enabled on the same device, clients may discover a device's IPv6 address that is not routable across your segmentation. The usual fix is to disable IPv6 on IoT/print VLANs, or scope the gateway to IPv4 answers only. Wireless clients that have IPv6 privacy extensions enabled often break AirPlay across VLANs for this reason.

Troubleshooting

Symptom                            Check
Device never appears               is the service type in the service-definition?
Appears then disappears            cache timeout vs device sleep (Bonjour sleep proxy)
Discovery works, connection fails  L3 reachability / firewall between VLANs
Works for one client only          client is on the same VLAN (local mDNS wins)
CPU spike on the gateway           service-definition too broad
IPv6-only answer unusable          disable IPv6 on the IoT VLAN

Related controls worth pairing with an mDNS policy: port isolation on guest WLANs and the anti-spoofing protections covered in Dynamic ARP Inspection and VLAN hopping prevention.

FAQ

Q: Can I just enable mDNS on the router? Routers do not reflect mDNS; you need a gateway/reflector feature on the switch, WLC or a dedicated appliance.
Q: Does this replace DNS-SD over unicast DNS? No — unicast DNS service discovery (RFC 6763 records served by DNS) is an alternative for wired networks and scales better, but Apple clients prefer mDNS when available.
Q: Is it safe to reflect from a guest VLAN? Only in the direction "guest queries corporate services", and even then only for specific types; the reverse direction exposes internal infrastructure to untrusted clients.

原文链接：https://www.rfc-editor.org/rfc/rfc6762.html