DNS resolution fails inside sandbox network namespace

[nic-nvidia]

Summary

DNS resolution does not work inside sandbox network namespaces. Applications that resolve DNS directly (rather than going through HTTP_PROXY) fail with:

Error: getaddrinfo EAI_AGAIN gateway.discord.gg

This breaks WebSocket connections, including Discord and WhatsApp integrations when running OpenClaw inside a sandbox.

Reproduction

openshell sandbox create --name dns-test --from openclaw --keep
openshell sandbox connect dns-test

# Inside sandbox:
nslookup example.com
# ;; communications error to 10.43.0.10#53: timed out
# ;; no servers could be reached

HTTP requests via curl and fetch work fine because they honor HTTP_PROXY and the proxy resolves DNS on their behalf. But WebSocket libraries (Discord.js, Baileys) and basic tools like nslookup resolve DNS directly and fail.

Root cause

The sandbox runs in an isolated network namespace where the only route is to the host side of the veth pair (10.200.0.1). The pod's /etc/resolv.conf points to CoreDNS (10.43.0.10), but the kube-proxy iptables DNAT rules that make that address routable only exist in the pod's original netns — not in the sandbox netns. Any direct DNS query times out.

Proposed fix

Run a lightweight UDP DNS forwarder on the host veth IP (10.200.0.1:53) that relays queries to the pod's upstream DNS server, and rewrite the sandbox's /etc/resolv.conf to point at it. The proxy still enforces network policy on TCP connections — DNS resolution alone does not grant network access.

I have a working implementation with tests at nic-nvidia#1 — happy to open a PR upstream if fork PRs are enabled.

Agent diagnostic context

Investigated with Claude Code pointed at the repo. The agent confirmed the issue is architectural (sandbox netns has no path to CoreDNS) and not a configuration problem. The debug-openshell-cluster skill does not cover this scenario. Tested the fix on a live OpenShell cluster — Discord WebSocket gateway connects successfully after the patch.

[johntmyers]

Which tool in OpenClaw is doing this? I know the web_fetch tool does it.

[johntmyers]

This currently would introduce additional ways out of the sandbox that reduce its security footprint. The underlying issue is that these tools should be able to adhere to the HTTPS_PROXY env var, DNS is just incidental. Even if DNS resolved, the connection would still attempt to bypass the proxy.