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:
-
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.
-
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.
-
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
- Switch from SLAAC to DHCPv6 with DNS update — Requires reconfiguring every router and host; not feasible on ISP-provided hardware.
- Add static AAAA records to Custom Zones — Static; breaks when privacy-extension addresses rotate.
- 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.
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:
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.
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.
Wildcard domain resources hit the same wall. A wildcard resource
*.home.lanwith 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: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
Additional context