[GH-ISSUE #5876] Feature request: per-network DNS namespace scoping for wildcard domain resources — fix multi-site SOHO domain collision #11872

Open
opened 2026-08-05 01:31:25 -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/5876

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

DNS Wildcard Routing (Settings → Networks → Enable DNS wildcard routing) lets a Network resource be defined as e.g. *.fritz.box and routes all matching DNS queries to a specific routing peer. This breaks silently when two or more routing peers are configured with the same wildcard domain.

SOHO routers ship with well-known default LAN domains: fritz.box (AVM FritzBox), home.arpa, local.lan, router.local, lan, etc. A user connecting three home networks — each running a FritzBox — will have three routing peers all legitimately owning *.fritz.box. Netbird can only assign the match-domain rule to one peer; the other two sites' hosts become unreachable by name with no error or warning.

Failure matrix:

Scenario Result
Site A and Site B both have a *.fritz.box wildcard resource Only one peer wins the match-domain rule; the other site's hosts are unresolvable by name
Admin has no control over SOHO router domain (ISP-provided hardware) No workaround exists
Admin can change router domain Must set unique suffixes per site — undocumented, error-prone

This also blocks any future use of Netbird DNS Wildcard Routing with the IANA .local pseudo-TLD, since every mDNS-capable LAN uses *.local.

Describe the solution you'd like

Allow per-network DNS namespace scoping so that each Network's wildcard domain resource is resolved exclusively by that network's routing peer(s), regardless of whether multiple networks share the same domain string. Options:

Option A — site-specific label prepended by the routing peer
The routing peer rewrites responses so that nas.fritz.box (resolved on Site A's peer) is also served as nas.fritz.box.site-a (or a configured alias), while Site B's same hostname is nas.fritz.box.site-b. Clients can use either form.

Option B — per-Network custom DNS zone mapped to wildcard resource
When DNS Wildcard Routing is enabled for a Network, require (or allow) the administrator to assign a unique zone alias (e.g. site-a) under which the wildcard resource's results are also published. Conflicts are detected at configuration time and rejected with an actionable error.

Option C — conflict detection + warning (minimum viable)
At minimum: detect when two wildcard domain resources in the same account share the same pattern and surface a dashboard warning, so the silent failure is visible.

Describe alternatives you've considered

  1. Require unique domain per site — Users with ISP-provided routers cannot change the router's domain. Not feasible universally.
  2. Use IP-based resources instead of wildcard domains — Loses all DNS-name usability; requires knowing all IPs in advance.
  3. Per-peer priority / fallback — Does not solve ambiguity, only changes which peer loses.

Additional context

  • This is an architectural limitation of the current DNS match-domain model, which uses the domain string as the sole routing key with no per-network scoping.
  • The same limitation applies to Netbird's nameserver match-domain feature (related: #4338, #5268), though the consequences there are less severe.
  • A companion issue (mDNS proxy for routing peers) proposes per-network Custom Zone suffixes as the mDNS discovery mechanism — that design inherently avoids this collision because each site uses a unique suffix configured by the administrator.
Originally created by @renne on GitHub (Apr 14, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5876 **Is your feature request related to a problem? Please describe.** DNS Wildcard Routing (Settings → Networks → Enable DNS wildcard routing) lets a Network resource be defined as e.g. `*.fritz.box` and routes all matching DNS queries to a specific routing peer. This breaks silently when two or more routing peers are configured with the same wildcard domain. SOHO routers ship with well-known default LAN domains: `fritz.box` (AVM FritzBox), `home.arpa`, `local.lan`, `router.local`, `lan`, etc. A user connecting three home networks — each running a FritzBox — will have three routing peers all legitimately owning `*.fritz.box`. Netbird can only assign the match-domain rule to one peer; the other two sites' hosts become unreachable by name with no error or warning. Failure matrix: | Scenario | Result | |---|---| | Site A and Site B both have a `*.fritz.box` wildcard resource | Only one peer wins the match-domain rule; the other site's hosts are unresolvable by name | | Admin has no control over SOHO router domain (ISP-provided hardware) | No workaround exists | | Admin can change router domain | Must set unique suffixes per site — undocumented, error-prone | This also blocks any future use of Netbird DNS Wildcard Routing with the IANA `.local` pseudo-TLD, since every mDNS-capable LAN uses `*.local`. **Describe the solution you'd like** Allow **per-network DNS namespace scoping** so that each Network's wildcard domain resource is resolved exclusively by that network's routing peer(s), regardless of whether multiple networks share the same domain string. Options: **Option A — site-specific label prepended by the routing peer** The routing peer rewrites responses so that `nas.fritz.box` (resolved on Site A's peer) is also served as `nas.fritz.box.site-a` (or a configured alias), while Site B's same hostname is `nas.fritz.box.site-b`. Clients can use either form. **Option B — per-Network custom DNS zone mapped to wildcard resource** When DNS Wildcard Routing is enabled for a Network, require (or allow) the administrator to assign a unique zone alias (e.g. `site-a`) under which the wildcard resource's results are also published. Conflicts are detected at configuration time and rejected with an actionable error. **Option C — conflict detection + warning (minimum viable)** At minimum: detect when two wildcard domain resources in the same account share the same pattern and surface a dashboard warning, so the silent failure is visible. **Describe alternatives you've considered** 1. **Require unique domain per site** — Users with ISP-provided routers cannot change the router's domain. Not feasible universally. 2. **Use IP-based resources instead of wildcard domains** — Loses all DNS-name usability; requires knowing all IPs in advance. 3. **Per-peer priority / fallback** — Does not solve ambiguity, only changes which peer loses. **Additional context** - This is an architectural limitation of the current DNS match-domain model, which uses the domain string as the sole routing key with no per-network scoping. - The same limitation applies to Netbird's nameserver match-domain feature (related: #4338, #5268), though the consequences there are less severe. - A companion issue (mDNS proxy for routing peers) proposes per-network Custom Zone suffixes as the mDNS discovery mechanism — that design inherently avoids this collision because each site uses a unique suffix configured by the administrator.
Author
Owner

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

Related issues (filed together):

  • #5875 — mDNS unicast proxy on routing peers (per-network Custom Zone suffixes proposed there are the direct solution to the collision described here)
  • #5877 — IPv6 SLAAC host routing and DNS name resolution (shares the same root cause: LAN host names not resolvable through routing peers)
<!-- gh-comment-id:4242062150 --> @renne commented on GitHub (Apr 14, 2026): **Related issues (filed together):** - #5875 — mDNS unicast proxy on routing peers (per-network Custom Zone suffixes proposed there are the direct solution to the collision described here) - #5877 — IPv6 SLAAC host routing and DNS name resolution (shares the same root cause: LAN host names not resolvable through routing peers)
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11872