[GH-ISSUE #5877] Feature request: IPv6 SLAAC host routing and DNS name resolution via subnet routing peers #12231

Open
opened 2026-08-05 01:32:42 -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/5877

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

Netbird subnet routing peers forward IPv4 and IPv6 traffic to LAN hosts, but DNS-based name resolution for IPv6 SLAAC hosts is fundamentally broken by design:

  1. SLAAC does not update DNS. IPv6 SLAAC (RFC 4862) derives interface IDs from MAC addresses (EUI-64) or privacy extensions. There is no DHCPv6 DNS update, no PTR record registration, no AAAA record — the host simply does not exist in DNS.

  2. Netbird's DNS route feature requires DNS. The "DNS Routes" feature (domain → routing peer → local DNS resolution) assumes a functional upstream DNS server with A/AAAA records for the routed domain. SLAAC hosts have none.

  3. Wildcard domain resources hit the same wall. A wildcard resource *.home.lan with DNS Wildcard Routing enabled forwards DNS queries to the routing peer's local resolver — but if the target host is SLAAC-only, there is nothing for the resolver to return.

Practical impact today: any SOHO or enterprise IPv6 deployment without a DHCPv6 server and DNS-update integration (stateless SLAAC is the default on most home routers) has LAN hosts that are IP-reachable through a Netbird subnet route but completely unreachable by hostname.

Future impact: when Netbird adds native IPv6 peer addressing or IPv6 subnet routing, SLAAC-only sites will be second-class citizens with no DNS name access.

Describe the solution you'd like

There are several complementary approaches, ideally implemented in increasing order of complexity:

Option A — NDP-based host table on routing peer (short term)
The routing peer scans its LAN for IPv6 neighbors (NDP / ip -6 neigh) and builds a name→AAAA mapping using either:

  • Reverse DNS (PTR lookup of the SLAAC address) if available
  • mDNS AAAA records if the host announces itself via mDNS

This table is then made available to Netbird's DNS forwarder and/or Custom Zone push (see companion mDNS proxy issue).

Option B — radvd / RDNSS integration (medium term)
If the routing peer runs radvd or a DHCPv6 server with DNS update support (e.g. dnsmasq with dhcp-script), Netbird could integrate with that local DNS to resolve SLAAC addresses by hostname.

Option C — Netbird-native SLAAC tracker (long term)
The routing peer monitors NDP traffic, correlates MAC→SLAAC addresses, and publishes AAAA records into a Netbird Custom Zone (same mechanism as the mDNS proxy proposal). Records are TTL-managed; hosts that stop responding to NDP probes are removed.

Describe alternatives you've considered

  1. Switch from SLAAC to DHCPv6 with DNS update — Requires reconfiguring every router and host; not feasible on ISP-provided hardware.
  2. Add static AAAA records to Custom Zones — Static; breaks when privacy-extension addresses rotate.
  3. Use IP addresses directly — Requires manually tracking unstable SLAAC addresses; not practical for users.

Additional context

  • Related companion issue: mDNS unicast proxy on routing peers — the NDP + mDNS discovery mechanism proposed there is the cleanest path to solving SLAAC name resolution as well (AAAA records from mDNS AAAA responses + NDP neighbor table).
  • RFC 6762 mDNS AAAA responses are the most widely deployed SLAAC name announcement mechanism on modern OSes (Linux avahi, macOS mDNSResponder, Windows mDNS).
  • Privacy extensions (RFC 8981) cause SLAAC addresses to rotate periodically — any solution must handle address churn without manual intervention.
Originally created by @renne on GitHub (Apr 14, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5877 **Is your feature request related to a problem? Please describe.** Netbird subnet routing peers forward IPv4 and IPv6 traffic to LAN hosts, but DNS-based name resolution for IPv6 SLAAC hosts is fundamentally broken by design: 1. **SLAAC does not update DNS.** IPv6 SLAAC (RFC 4862) derives interface IDs from MAC addresses (EUI-64) or privacy extensions. There is no DHCPv6 DNS update, no PTR record registration, no AAAA record — the host simply does not exist in DNS. 2. **Netbird's DNS route feature requires DNS.** The "DNS Routes" feature (domain → routing peer → local DNS resolution) assumes a functional upstream DNS server with A/AAAA records for the routed domain. SLAAC hosts have none. 3. **Wildcard domain resources hit the same wall.** A wildcard resource `*.home.lan` with DNS Wildcard Routing enabled forwards DNS queries to the routing peer's local resolver — but if the target host is SLAAC-only, there is nothing for the resolver to return. Practical impact today: any SOHO or enterprise IPv6 deployment without a DHCPv6 server and DNS-update integration (stateless SLAAC is the default on most home routers) has LAN hosts that are IP-reachable through a Netbird subnet route but completely unreachable by hostname. Future impact: when Netbird adds native IPv6 peer addressing or IPv6 subnet routing, SLAAC-only sites will be second-class citizens with no DNS name access. **Describe the solution you'd like** There are several complementary approaches, ideally implemented in increasing order of complexity: **Option A — NDP-based host table on routing peer (short term)** The routing peer scans its LAN for IPv6 neighbors (NDP / `ip -6 neigh`) and builds a name→AAAA mapping using either: - Reverse DNS (PTR lookup of the SLAAC address) if available - mDNS AAAA records if the host announces itself via mDNS This table is then made available to Netbird's DNS forwarder and/or Custom Zone push (see companion mDNS proxy issue). **Option B — radvd / RDNSS integration (medium term)** If the routing peer runs radvd or a DHCPv6 server with DNS update support (e.g. dnsmasq with `dhcp-script`), Netbird could integrate with that local DNS to resolve SLAAC addresses by hostname. **Option C — Netbird-native SLAAC tracker (long term)** The routing peer monitors NDP traffic, correlates MAC→SLAAC addresses, and publishes AAAA records into a Netbird Custom Zone (same mechanism as the mDNS proxy proposal). Records are TTL-managed; hosts that stop responding to NDP probes are removed. **Describe alternatives you've considered** 1. **Switch from SLAAC to DHCPv6 with DNS update** — Requires reconfiguring every router and host; not feasible on ISP-provided hardware. 2. **Add static AAAA records to Custom Zones** — Static; breaks when privacy-extension addresses rotate. 3. **Use IP addresses directly** — Requires manually tracking unstable SLAAC addresses; not practical for users. **Additional context** - Related companion issue: mDNS unicast proxy on routing peers — the NDP + mDNS discovery mechanism proposed there is the cleanest path to solving SLAAC name resolution as well (AAAA records from mDNS AAAA responses + NDP neighbor table). - RFC 6762 mDNS AAAA responses are the most widely deployed SLAAC name announcement mechanism on modern OSes (Linux avahi, macOS mDNSResponder, Windows mDNS). - Privacy extensions (RFC 8981) cause SLAAC addresses to rotate periodically — any solution must handle address churn without manual intervention.
Author
Owner

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

Related issues (filed together):

  • #5875 — mDNS unicast proxy on routing peers (NDP + mDNS discovery mechanism proposed there directly addresses SLAAC AAAA name resolution)
  • #5876 — Wildcard DNS domain conflict for multi-site SOHO deployments (companion architectural issue; per-network zone suffixes solve both)
<!-- gh-comment-id:4242062780 --> @renne commented on GitHub (Apr 14, 2026): **Related issues (filed together):** - #5875 — mDNS unicast proxy on routing peers (NDP + mDNS discovery mechanism proposed there directly addresses SLAAC AAAA name resolution) - #5876 — Wildcard DNS domain conflict for multi-site SOHO deployments (companion architectural issue; per-network zone suffixes solve both)
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#12231