`netbird kubernetes list/write-kubeconfig` fails with "lookup …in-addr.arpa: no such host" — reverse lookups go to the system resolver instead of NetBird's

Environment

• NetBird client 0.77.1 and 0.78.1 (macOS 15, Apple Silicon); self-hosted management
• Kubernetes operator 0.8.0 with a working ClusterProxy (peers connected, Ready=True)
• Client DNS management enabled; no nameserver groups configured initially

Steps

1. Have a ClusterProxy registered and reachable.
2. Run netbird kubernetes list (or netbird kubernetes write-kubeconfig <cluster>).

Actual

Error: lookup z.y.x.100.in-addr.arpa. on <upstream resolver>:53: no such host

The IP in the error is an arbitrary other peer in the network (an offline tablet, a laptop), not the proxy. The command aborts on the first peer whose PTR the resolver cannot answer. Nothing is listed.

Analysis

• The lookup is performed against the address in /etc/resolv.conf (the upstream resolver), not against NetBird's embedded resolver, and it is fatal.
• On macOS, NetBird installs a scoped resolver only for the account domain (*.nb.<domain>), so in-addr.arpa queries never reach it. Adding a nameserver group matching the mesh /16 reverse zone makes the OS route PTRs correctly (dig -x <peer-ip> @<NetBird resolver IP> answers), but the daemon still queries the upstream resolver directly — GODEBUG=netdns=cgo makes no difference — so that fix has no effect on the CLI.
• The client already holds every peer's IP→FQDN mapping; a DNS round-trip is unnecessary to display it.

Workaround (works, but changes system DNS for every affected peer): a primary nameserver group for the operator peers, so NetBird's resolver becomes the system resolver and the daemon's PTR queries land on it. After that, list and write-kubeconfig work.

Suggested fix

1. Resolve peer display names from the daemon's own peer store (or its embedded resolver), never via the system resolver.
2. Make PTR failures non-fatal: show the IP and continue — one unresolvable peer should not hide every cluster.