Linux: embedded DNS resolver on wt0 IP never answers queries from the local machine (cross-peer queries work) — v0.78.1

Describe the problem

On Linux peers running v0.78.1, the embedded DNS resolver does not answer any query originating from the peer's own machine, so *.netbird.cloud names cannot be resolved locally. The resolver socket is bound and listening on the peer's wt0 IP, systemd-resolved is correctly configured to use it for the netbird.cloud domain, but every query sent to it from the local host — via systemd-resolved, or via a raw UDP/TCP socket — times out silently (no reply, no ICMP/RST).

The same resolver does answer queries arriving over the tunnel from another peer, returning correct records. So the DNS service itself is healthy; only the loopback-path delivery to it appears broken.

Reproduced identically on two independent machines (different distros, kernels, firewall setups).

To Reproduce

On a Linux peer (kernel WireGuard interface, systemd-resolved):

$ ss -lun 'sport = :53'
UNCONN 0 0 100.120.x.x:53 0.0.0.0:*        # netbird resolver bound on own wt0 IP

$ resolvectl status wt0
Current DNS Server: 100.120.x.x
DNS Domain: netbird.cloud ~...in-addr.arpa ...

$ resolvectl query <other-peer>.netbird.cloud
resolve call failed: Query timed out

# raw UDP query straight at the resolver — also no reply:
$ python3 -c '<send single A query to 100.120.x.x:53, 3s timeout>'
TIMEOUT

# TCP/53 to the same address: connection times out (SYN silently dropped/ignored — no RST,
# so this is not a missing-listener case)

Meanwhile from another peer over the tunnel, the same resolver answers instantly:

other-peer$ <same raw UDP query to 100.120.x.x:53>
reply received, A = <correct peer IP>

Expected behavior

Queries from the local machine to the peer's own embedded resolver (as configured by NetBird into systemd-resolved) should be answered, so local resolution of *.netbird.cloud names works.

What we ruled out

• Host firewalls: verified on both machines. On one machine ufw is active but accepts -i lo; a third-party VPN's (PIA) DNS-blocking chains were confirmed unlinked/inactive during testing. The second machine (a plain Linode VM) has none of that and shows the identical symptom.
• NetBird's own nftables rules (table ip netbird): the ACL input chain only filters iifname "wt0"; these queries arrive via lo (destination is a local address), so they never hit those rules. Chain counters confirm no drops there.
• Routing: ip route get <own wt0 IP> → local ... dev lo as expected; delivery is plain loopback.
• NB_USE_LEGACY_DNS_RESOLUTION=true: set via systemd override on both peers (confirmed present in the daemon's environment, daemon restarted) — no change.
• Source-address variations (default src = wt0 IP, and 127.0.0.1) both time out; UDP and TCP both affected.

Environment

• Machine 1: Pop!_OS 22.04 LTS, kernel 7.1.1-76070101-generic, systemd 249 (systemd-resolved with stub at 127.0.0.53)
• Machine 2: Ubuntu 24.04.4 LTS (Linode VM), kernel 7.1.9-x86_64-linode176, systemd 255
• NetBird daemon/CLI: 0.78.1 on both, NetBird Cloud (app.netbird.io)
• Interface type: Kernel WireGuard (wt0), lazy connection enabled
• Machine 1 enrolled via SSO; Machine 2 via setup key (service peer) — same behavior

Additional context

Because the resolver answers over the tunnel but not via loopback, this looks like the DNS listener only receives packets that arrive on the wt0 device (e.g. a socket bound with SO_BINDTODEVICE/equivalent, or an interface-scoped capture path), while queries addressed to the wt0 IP from the local host are delivered by the kernel via lo and never reach it. Happy to collect debug bundles or packet captures from either machine if useful.