Reverse Proxy: Custom domain pushed as DNS search domain to all peers, breaking local hostname resolution

[blaugrau90]

Describe the problem

When a reverse proxy service is configured in NetBird using a custom domain (e.g. app.example.com), NetBird automatically pushes that domain as a search domain to all connected peers — not just as a supplemental resolver.

This inserts the reverse proxy domain before the peer's existing local search domains (e.g. pushed via DHCP), causing short hostname lookups to match the reverse proxy domain first and never reach the local DNS search domains.

To Reproduce

1. Configure a reverse proxy in NetBird with a custom domain (e.g. app.example.com)
2. Enable at least one service on that reverse proxy
3. On a macOS peer, run scutil --dns
4. Observe: app.example.com appears in the search domain list of the primary resolver, ahead of locally configured search domains

resolver #1
  search domain[0] : nb.cloud
  search domain[1] : app.example.com    ← injected by reverse proxy feature
  search domain[2] : internal.lan       ← local search domain pushed via DHCP
  nameserver[0] : 10.x.x.x

5. Disable the service in NetBird
6. Run scutil --dns again
7. Observe: app.example.com is gone — local search domains remain

Expected behavior

app.example.com should only be registered as a supplemental resolver (so that explicit queries for *.app.example.com go through NetBird's DNS), but not added as a search domain suffix that is applied to unqualified hostnames.

Actual behavior

app.example.com is injected as a search domain ahead of the peer's local DNS search domains. If any DNS record exists under app.example.com that matches a local short hostname (e.g. myserver.app.example.com), the local host with that name becomes unreachable — the reverse proxy domain wins silently and the local search domains are never tried.

Impact

• Local hostnames silently resolve to wrong IPs (reverse proxy / public server)
• Local DNS search domains pushed via DHCP are effectively shadowed and ignored for any hostname that has a matching record in the reverse proxy domain
• Ansible, SSH, and other tooling connects to unexpected hosts without any error
• Bug appears and disappears dynamically as services are toggled — very hard to diagnose

Environment

• OS: macOS
• NetBird client version: v0.73.1
• NetBird daemon version: v0.73.1
• Verified with: scutil --dns (macOS DNS resolver configuration)

Workaround

Disable all reverse proxy services → search domain disappears and local resolution works again. Not a viable long-term fix.

[blaugrau90]

Root Cause Found + Fix Verified

After digging into the NetBird source code, I found the exact cause and confirmed a fix works.

Root Cause

In management/server/types/account.go, the function SynthesizePrivateServiceZones creates CustomZone entries for reverse proxy services without setting SearchDomainDisabled:

// current code
zone = &nbdns.CustomZone{
    Domain:           dns.Fqdn(serviceDomainZone),
    Records:          []nbdns.SimpleRecord{},
    NonAuthoritative: true,
    // SearchDomainDisabled not set → defaults to false → domain gets pushed as search domain
}

In Go, an unset bool defaults to false, so SearchDomainDisabled = false → the domain is treated as a search domain and pushed to all peers. This is inconsistent with how user-configured DNS zones work, where SearchDomainDisabled is explicitly set via !zone.EnableSearchDomain.

The reverse proxy zone also gets assigned DNS order 102801 (same range as Magic DNS nb.cloud at 102800), rather than the 103xxx range used by nameserver groups — confirming it goes through a different, higher-priority code path that bypasses the user-controlled search domain toggle.

Fix

Adding SearchDomainDisabled: true to the zone creation in SynthesizePrivateServiceZones:

zone = &nbdns.CustomZone{
    Domain:               dns.Fqdn(serviceDomainZone),
    Records:              []nbdns.SimpleRecord{},
    NonAuthoritative:     true,
    SearchDomainDisabled: true,
}

Verification

Tested on a self-hosted NetBird stack with the patched netbird-server binary:

Before fix (scutil --dns on macOS peer, reverse proxy service active):

resolver #1
  search domain[0] : nb.cloud
  search domain[1] : app.example.com    ← injected by reverse proxy
  search domain[2] : internal.lan

After fix (same peer, same reverse proxy service still active):

resolver #1
  search domain[0] : nb.cloud
  search domain[1] : internal.lan       ← app.example.com gone

Short hostname resolution now correctly falls through to local DNS search domains instead of matching the reverse proxy domain first.