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