[GH-ISSUE #5875] Feature request: mDNS unicast proxy on routing peers — merge subnet .local names into a per-network Netbird Custom Zone #11868

Open
opened 2026-08-05 01:31:24 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @renne on GitHub (Apr 14, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5875

Is your feature request related to a problem? Please describe.

mDNS (RFC 6762) is link-local multicast (224.0.0.251:5353) — it never crosses subnet boundaries. Devices on a remote LAN that advertise themselves via mDNS (nas.local, printer.local, homeassistant.local) are completely invisible to Netbird peers reaching that subnet through a routing peer, even when the IP subnet is routed correctly.

Additionally, when Netbird itself gains IPv6 SLAAC support for routing peers, the same problem will arise for any SLAAC-addressed LAN host: SLAAC does not register DNS records, so Netbird's DNS route feature and domain resources cannot resolve those hosts by name.

Concrete example:

  • Site A: routing peer on 192.168.1.1/24; NAS on 192.168.1.50 announces nas.local via mDNS
  • Remote Netbird peer can ping 192.168.1.50 via the subnet route, but nas.local never resolves
  • Only workaround: add a static Custom Zone record — brittle, doesn't survive DHCP lease changes, doesn't scale

Describe the solution you'd like

An optional mDNS unicast proxy on routing peers that:

  1. Listens on the LAN interface for mDNS announcements (RFC 6762)
  2. Maintains a live cache of discovered PTR / A / AAAA / SRV records
  3. Auto-populates a Netbird Custom Zone with a user-defined per-network suffix (e.g. site-a.home) with the discovered records, pushed to clients via the management server

Example configuration in the Network / routing-peer settings:

mDNS proxy zone: site-a.home

Result: a remote Netbird peer resolves nas.site-a.home192.168.1.50 without any static DNS entry.

When the mDNS TTL expires or the host disappears, the record is removed automatically.

A user-defined zone suffix per network is essential to avoid collisions when multiple sites use the same SOHO default domain (e.g., two sites both having a nas.local) — each site gets its own non-overlapping suffix.

Describe alternatives you've considered

  1. Custom Zones manual entry — Brittle, per-record maintenance, not auto-discovered.
  2. Dedicated LAN DNS server (Pi-hole, BIND, avahi) — Viable but requires extra infrastructure many SOHO/home users don't have.
  3. Static DHCP + manual DNS records — Defeats the purpose of mDNS auto-discovery.

Additional context

  • Related: #3698 — Netbird's old DNS forwarder accidentally used mDNS port 5353 (collision). Fixed in v0.59.0 → port 22054. This request is different: it is about using mDNS as a name discovery source, not about the port conflict.
  • Future relevance: once Netbird routing peers support IPv6 SLAAC-addressed LAN hosts, the same gap applies — SLAAC hosts have no DNS records; an mDNS / NDP-based discovery mechanism on the routing peer is the only way to make them addressable by name through Netbird.
  • Prior art: avahi-daemon unicast bridge, mdns-repeater, systemd-resolved mDNS integration.
  • User-defined per-network zone suffixes also solve the multi-site same-domain collision described in a separately filed companion issue (wildcard DNS domain conflict for multi-site SOHO deployments).
Originally created by @renne on GitHub (Apr 14, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5875 **Is your feature request related to a problem? Please describe.** mDNS (RFC 6762) is link-local multicast (224.0.0.251:5353) — it never crosses subnet boundaries. Devices on a remote LAN that advertise themselves via mDNS (`nas.local`, `printer.local`, `homeassistant.local`) are completely invisible to Netbird peers reaching that subnet through a routing peer, even when the IP subnet is routed correctly. Additionally, when Netbird itself gains IPv6 SLAAC support for routing peers, the same problem will arise for any SLAAC-addressed LAN host: SLAAC does not register DNS records, so Netbird's DNS route feature and domain resources cannot resolve those hosts by name. Concrete example: - Site A: routing peer on `192.168.1.1/24`; NAS on `192.168.1.50` announces `nas.local` via mDNS - Remote Netbird peer can ping `192.168.1.50` via the subnet route, but `nas.local` never resolves - Only workaround: add a static Custom Zone record — brittle, doesn't survive DHCP lease changes, doesn't scale **Describe the solution you'd like** An optional **mDNS unicast proxy** on routing peers that: 1. Listens on the LAN interface for mDNS announcements (RFC 6762) 2. Maintains a live cache of discovered PTR / A / AAAA / SRV records 3. Auto-populates a Netbird **Custom Zone** with a user-defined per-network suffix (e.g. `site-a.home`) with the discovered records, pushed to clients via the management server Example configuration in the Network / routing-peer settings: ``` mDNS proxy zone: site-a.home ``` Result: a remote Netbird peer resolves `nas.site-a.home` → `192.168.1.50` without any static DNS entry. When the mDNS TTL expires or the host disappears, the record is removed automatically. A user-defined zone suffix per network is essential to avoid collisions when multiple sites use the same SOHO default domain (e.g., two sites both having a `nas.local`) — each site gets its own non-overlapping suffix. **Describe alternatives you've considered** 1. **Custom Zones manual entry** — Brittle, per-record maintenance, not auto-discovered. 2. **Dedicated LAN DNS server (Pi-hole, BIND, avahi)** — Viable but requires extra infrastructure many SOHO/home users don't have. 3. **Static DHCP + manual DNS records** — Defeats the purpose of mDNS auto-discovery. **Additional context** - Related: #3698 — Netbird's old DNS forwarder accidentally used mDNS port 5353 (collision). Fixed in v0.59.0 → port 22054. This request is different: it is about using mDNS as a *name discovery source*, not about the port conflict. - Future relevance: once Netbird routing peers support IPv6 SLAAC-addressed LAN hosts, the same gap applies — SLAAC hosts have no DNS records; an mDNS / NDP-based discovery mechanism on the routing peer is the only way to make them addressable by name through Netbird. - Prior art: avahi-daemon unicast bridge, mdns-repeater, systemd-resolved mDNS integration. - User-defined per-network zone suffixes also solve the multi-site same-domain collision described in a separately filed companion issue (wildcard DNS domain conflict for multi-site SOHO deployments).
Author
Owner

@renne commented on GitHub (Apr 14, 2026):

Related issues (filed together):

  • #5876 — Wildcard DNS domain conflict for multi-site SOHO deployments (same-domain routing ambiguity that per-network zone suffixes would also solve)
  • #5877 — IPv6 SLAAC host routing and DNS name resolution (NDP + mDNS discovery on routing peer is the shared solution path)
<!-- gh-comment-id:4242061434 --> @renne commented on GitHub (Apr 14, 2026): **Related issues (filed together):** - #5876 — Wildcard DNS domain conflict for multi-site SOHO deployments (same-domain routing ambiguity that per-network zone suffixes would also solve) - #5877 — IPv6 SLAAC host routing and DNS name resolution (NDP + mDNS discovery on routing peer is the shared solution path)
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11868