netbird kubernetes list fails when any peer has no PTR record

[mtb-xt]

Hi NetBird folks,

We have been testing the new Kubernetes API server proxy flow from:

• https://docs.netbird.io/manage/integrations/kubernetes/api-server-proxy
• [client] Add commands to discover and write Kubernetes configuration netbird#6260

The proxy itself looks good so far. The operator reconciles the ClusterProxy, the proxy peers join the expected NetBird group, and a manual kubeconfig pointed at:

https://<cluster>.netbird-kubeapi-proxy.<netbird-dns-domain>

can reach the Kubernetes API through NetBird.

The problem is that netbird kubernetes list fails before it can list the cluster if any peer in the network map has no reverse DNS record.

Example from Linux with NetBird CLI/daemon 0.73.2:

$ netbird kubernetes list
Error: lookup <redacted>.in-addr.arpa. on 127.0.0.53:53: no such host

Example from Windows with NetBird CLI/daemon 0.73.2:

PS C:\> netbird kubernetes list
Error: lookup <redacted>.in-addr.arpa. on [fd82:...]:53: server misbehaving

That Windows peer otherwise looked healthy:

Management: Connected
Signal: Connected
Relays: 2/2 Available
Peers count: 24/24 Connected

I think the failure is here:

https://github.com/netbirdio/netbird/blob/main/client/cmd/kubernetes.go

Current behavior in getKubernetesClusters:

fqdns, err := resolver.LookupAddr(ctx, peer.IP)
if err != nil {
    return nil, err
}

So one ordinary peer without a PTR record aborts the whole Kubernetes discovery command. In our setup, the actual Kubernetes proxy peers do have the expected extra DNS label:

<cluster>.netbird-kubeapi-proxy.<netbird-dns-domain>

but the CLI never gets that far because it returns on an unrelated peer's PTR lookup failure.

Expected behavior:

• peers without PTR should be skipped, probably with debug logging
• netbird kubernetes list should still list reachable Kubernetes proxy peers
• netbird kubernetes write-kubeconfig <cluster> should not require every unrelated peer in the network map to have reverse DNS

Our local workaround is to create the kubeconfig manually with the proxy FQDN:

kubectl config set-cluster <cluster> \
  --server=https://<cluster>.netbird-kubeapi-proxy.<netbird-dns-domain> \
  --insecure-skip-tls-verify=true
kubectl config set-credentials netbird --token=none
kubectl config set-context <cluster> --cluster=<cluster> --user=netbird --namespace=<namespace>

That is fine for testing, but it is not something we can reasonably ask every developer to do.

Would you be open to a small PR that makes PTR lookup failures non-fatal in Kubernetes discovery, plus a regression test?

[jnfrati]

Transfering this one to the operator repo so it's easier to track 🙌

[ashish1099]

I have seen this issue, its most likely the policy issue, so look hard around that