box/host
claude-hdb a2c0758ba6 fix: pin claudenet's resolver — a box's DNS is not a function of the host's VPN
The bridge's dnsmasq forwarded to whatever sat in the host's
/etc/resolv.conf at that moment. On a Tailscale host that is MagicDNS:
box DNS flapped with the tailnet (killing cold mints), and tailnet peer
names and split-DNS zones resolved from inside a box — name-level
reconnaissance of a private network, the same class as the sibling
enumeration dns.mode=none already closes.

setup-host.sh now sets raw.dnsmasq to no-resolv + pinned public
upstreams (BOX_DNS overrides the default 1.1.1.1 8.8.8.8), answering
the issue's three open questions from live measurement: raw.dnsmasq is
the lever (no first-class upstream key on the bridge; verified by
doctor --pin-dns followed by a box resolving), upstreams are a setting
with a sane default, and the pin is unconditional.

The doctor's unpinned-state messages now point at setup-host.sh as the
durable fix, keeping --pin-dns as the quick test.

Closes #33
2026-07-14 12:15:45 +00:00
..
claudebox-firewall.service Import claudebox: creds-free, trust-less Claude Code VMs 2026-07-10 15:00:36 +00:00
claudebox-firewall.sh fix: boxes could reach each other — isolate them at the bridge 2026-07-14 01:29:33 +00:00
setup-host.sh fix: pin claudenet's resolver — a box's DNS is not a function of the host's VPN 2026-07-14 12:15:45 +00:00
teardown-host.sh feat: drop the claude- instance-name prefix; tag boxes instead 2026-07-10 17:09:45 +00:00