fix(netbird-server): keep the host mesh client out of DNS #1427

2026-10-22T19:55:23Z

claude-bot commented

2026-10-22 19:55:23 +00:00

Problem

After the update-os reboot on 2026-10-22 (pipeline #14710), Uptime Kuma on netbird.renner.uno marked all 76 HTTP/keyword/json-query monitors DOWN. DNS monitors stayed UP.

The controller's own NetBird client (0.81.3, not managed by any role) registered ~renner.uno on wt0 in systemd-resolved, forwarding to the kube-dns-lb nameserver group (10.2.99.83 / fd99::83). That group is unreachable from this peer (netbird status: Nameserver group unreachable), so resolvectl query home.renner.uno returned SERVFAIL. Kuma resolves through Docker's embedded DNS → host stub, so its checks hung before connecting (no SYN on the wire).

Change

netbird-server role: if /usr/bin/netbird exists and netbird debug config shows disableDns: false, run netbird down + netbird up --disable-dns. A connected client ignores the flag on up, hence the down/up. No-op once disableDns is true.

Verification

Applied live 2026-10-22 ~19:40 UTC with the same commands: disableDns: true, home.renner.uno resolves publicly via proxy.renner.uno, all Kuma HTTP monitors UP within ~1 min, no container restart.
ansible-playbook --syntax-check plays/install-netbird-server.yml passes.
On merge, deploy-netbird-server runs; on the current host the new task is skipped (already disabled).

🤖 Generated with Claude Code

## Problem After the update-os reboot on 2026-10-22 (pipeline #14710), Uptime Kuma on netbird.renner.uno marked all 76 HTTP/keyword/json-query monitors DOWN. DNS monitors stayed UP. The controller's own NetBird client (0.81.3, not managed by any role) registered `~renner.uno` on `wt0` in systemd-resolved, forwarding to the kube-dns-lb nameserver group (`10.2.99.83` / `fd99::83`). That group is unreachable from this peer (`netbird status`: *Nameserver group unreachable*), so `resolvectl query home.renner.uno` returned SERVFAIL. Kuma resolves through Docker's embedded DNS → host stub, so its checks hung before connecting (no SYN on the wire). ## Change `netbird-server` role: if `/usr/bin/netbird` exists and `netbird debug config` shows `disableDns: false`, run `netbird down` + `netbird up --disable-dns`. A connected client ignores the flag on `up`, hence the down/up. No-op once disableDns is true. ## Verification - Applied live 2026-10-22 ~19:40 UTC with the same commands: `disableDns: true`, `home.renner.uno` resolves publicly via proxy.renner.uno, all Kuma HTTP monitors UP within ~1 min, no container restart. - `ansible-playbook --syntax-check plays/install-netbird-server.yml` passes. - On merge, deploy-netbird-server runs; on the current host the new task is skipped (already disabled). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-10-22 19:55:23 +00:00

fix(netbird-server): keep the host mesh client out of DNS

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

29c299c0fe

The controller's own NetBird client registered ~renner.uno in
systemd-resolved, pointing at the kube-dns-lb nameserver group, which is
unreachable from this peer. Every *.renner.uno lookup on the host returned
SERVFAIL, and Uptime Kuma, resolving through Docker's embedded DNS and the
host stub, marked all HTTP monitors DOWN after the 2026-10-22 update-os
reboot.

The role now reconnects the client with --disable-dns when its config has
DNS management enabled. The flag is only honoured on a fresh up, so the
task runs netbird down + up; it is a no-op once disableDns is true.
Applied live and verified 2026-10-22 before this commit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

review-bot reviewed

2026-10-22 19:55:57 +00:00

review-bot left a comment

🤖 Automated review — model claude-sonnet-5-5, commit 29c299c0fe32aaf397a713dfa1687ed6971d26f6.

Automated review by the review-bot: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review.

Summary

This PR adds three tasks to the netbird-server role. If /usr/bin/netbird exists and netbird debug config reports disableDns: false, they run netbird down and then netbird up --disable-dns. This stops the host's mesh client from registering an unreachable ~renner.uno route in systemd-resolved. The change is small and gated so it does nothing once the setting is applied. I found no verified defect, but the reconnect step has a few failure modes that the PR does not address.

Mergeable is true and the base is main at a3efc511. The last change to this file on main was adbfd3bf (2026-09-25), so the PR does not conflict with it. No other PR, issue or role in the repo does the same thing. The netbird-client role only does netbird up with a setup key and does not manage DNS. No issues are linked, and there are no earlier reviews or comments.

⚪ Unverified

ansible/roles/netbird-server/tasks/main.yml:168 runs netbird debug config, and line 181 parses its stdout with from_json and reads .disableDns. I cannot confirm that subcommand's output format or key name for client 0.81.3. The PR says it was run live, so I'm not treating this as a defect. If the output has a non-JSON prefix, or if the key is missing in a config that has never set it, the task fails with a templating error. A | default(false) would be safer. If the daemon is stopped, debug config fails and so does the whole play.
main.yml:175-178 runs netbird down and then netbird up --disable-dns with no setup key and no timeout. I assumed up reuses the stored login. If the peer's login has expired or been revoked, up may wait for interactive SSO and hang the pipeline, or fail with the client left down. set -eu stops the script after a failed up, but it doesn't bring the client back up. I could not check this against the host.
I did not check whether the deploy connects to this host over the NetBird mesh. If it does, netbird down would drop the Ansible connection. The inventory was not readable through the tools, so I could not look.

🟡 Suggestions

main.yml:181: add | default(false) to the disableDns lookup. Alternatively, add failed_when: false to the read task and skip the reconnect when the output can't be parsed.
main.yml:174: add a timeout, for example timeout 60 netbird up --disable-dns. Without one, an unexpected prompt can hang the deploy.
main.yml:174: the task always reports changed when it runs, which is correct, but you may want changed_when and register so the result of the reconnect is visible. A follow-up netbird status or a re-read of the config would confirm disableDns is now true.
main.yml:160: the block sits after the 10-second "Wait for management container" pause and before the status debug task. It doesn't depend on the containers, so it could go earlier. This is not important.

Tests

There is no automated test, and the repo's roles don't appear to have any. The author reports a syntax check and a live run on the affected host. If a molecule or CI check is added later, it should cover three cases: the binary is absent, disableDns is already true (the task is skipped), and disableDns is false (the reconnect runs).

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `claude-sonnet-5-5`, commit `29c299c0fe32aaf397a713dfa1687ed6971d26f6`. > Automated review by the `review-bot`: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review. --- ## Summary This PR adds three tasks to the `netbird-server` role. If `/usr/bin/netbird` exists and `netbird debug config` reports `disableDns: false`, they run `netbird down` and then `netbird up --disable-dns`. This stops the host's mesh client from registering an unreachable `~renner.uno` route in systemd-resolved. The change is small and gated so it does nothing once the setting is applied. I found no verified defect, but the reconnect step has a few failure modes that the PR does not address. Mergeable is true and the base is `main` at `a3efc511`. The last change to this file on `main` was `adbfd3bf` (2026-09-25), so the PR does not conflict with it. No other PR, issue or role in the repo does the same thing. The `netbird-client` role only does `netbird up` with a setup key and does not manage DNS. No issues are linked, and there are no earlier reviews or comments. ## ⚪ Unverified - `ansible/roles/netbird-server/tasks/main.yml:168` runs `netbird debug config`, and line 181 parses its stdout with `from_json` and reads `.disableDns`. I cannot confirm that subcommand's output format or key name for client 0.81.3. The PR says it was run live, so I'm not treating this as a defect. If the output has a non-JSON prefix, or if the key is missing in a config that has never set it, the task fails with a templating error. A `| default(false)` would be safer. If the daemon is stopped, `debug config` fails and so does the whole play. - `main.yml:175-178` runs `netbird down` and then `netbird up --disable-dns` with no setup key and no timeout. I assumed `up` reuses the stored login. If the peer's login has expired or been revoked, `up` may wait for interactive SSO and hang the pipeline, or fail with the client left down. `set -eu` stops the script after a failed `up`, but it doesn't bring the client back up. I could not check this against the host. - I did not check whether the deploy connects to this host over the NetBird mesh. If it does, `netbird down` would drop the Ansible connection. The inventory was not readable through the tools, so I could not look. ## 🟡 Suggestions - `main.yml:181`: add `| default(false)` to the `disableDns` lookup. Alternatively, add `failed_when: false` to the read task and skip the reconnect when the output can't be parsed. - `main.yml:174`: add a `timeout`, for example `timeout 60 netbird up --disable-dns`. Without one, an unexpected prompt can hang the deploy. - `main.yml:174`: the task always reports `changed` when it runs, which is correct, but you may want `changed_when` and `register` so the result of the reconnect is visible. A follow-up `netbird status` or a re-read of the config would confirm `disableDns` is now true. - `main.yml:160`: the block sits after the 10-second "Wait for management container" pause and before the status debug task. It doesn't depend on the containers, so it could go earlier. This is not important. ## Tests There is no automated test, and the repo's roles don't appear to have any. The author reports a syntax check and a live run on the affected host. If a molecule or CI check is added later, it should cover three cases: the binary is absent, `disableDns` is already true (the task is skipped), and `disableDns` is false (the reconnect runs). ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

k.renner merged commit c6cb6b3aec into main

2026-10-22 19:56:52 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#1427