Promote smolmachines to default backend; convert Docker backend to example-only (resolves DNS sinkhole gap) #206

New Issue

2026-06-06T13:59:36-04:00

didericis-claude commented

2026-06-06 13:59:36 -04:00

The egress mitmproxy addon (PRD 0052/0053) is an HTTP proxy: it intercepts HTTPS connections and scans HTTP request/response surfaces. Raw UDP port-53 DNS queries go to the OS resolver and never pass through it.

This means an agent can exfiltrate data via DNS tunnelling — encoding secrets as base32 or hex subdomains in a DNS query — and the egress proxy will not see it at all. The hostname scan added in PRD 0053 catches secrets encoded in the hostname of an HTTP request, but has no effect on actual DNS packets.

What's needed

A controlled DNS resolver (dnsmasq or CoreDNS) that:

Is the only resolver reachable from the agent container (iptables blocks outbound UDP/TCP 53 to anything else).
Only resolves allowlisted hostnames; all other queries receive NXDOMAIN.
Ideally: rejects queries with unexpected subdomain depth for allowlisted zones (e.g. rejects <encoded>.api.anthropic.com — anthropic's zone has no legitimate deep subdomains).

The network egress guard research doc (docs/research/network-egress-guard.md) covers this under "Approach 4: DNS-based egress control" and notes it pairs with the in-container iptables approach.

Scope

Add a dnsmasq (or CoreDNS) sidecar or in-container resolver.
Generate its allowlist from the bottle manifest's egress.routes host list.
Block outbound UDP/TCP 53 to non-local resolvers via iptables.
Document the residual gap: an agent that controls a subdomain of an allowlisted zone could still exfiltrate through forwarded queries (see research doc).

References

docs/research/network-egress-guard.md — Approach 4
docs/research/secret-exfil-tripwire-encodings.md — DNS exfil discussion
PRD 0053 (HTTP-level hostname scan — partial mitigation only)

The egress mitmproxy addon (PRD 0052/0053) is an HTTP proxy: it intercepts HTTPS connections and scans HTTP request/response surfaces. Raw UDP port-53 DNS queries go to the OS resolver and never pass through it. This means an agent can exfiltrate data via DNS tunnelling — encoding secrets as base32 or hex subdomains in a DNS query — and the egress proxy will not see it at all. The hostname scan added in PRD 0053 catches secrets encoded *in the hostname of an HTTP request*, but has no effect on actual DNS packets. ## What's needed A controlled DNS resolver (dnsmasq or CoreDNS) that: 1. Is the only resolver reachable from the agent container (iptables blocks outbound UDP/TCP 53 to anything else). 2. Only resolves allowlisted hostnames; all other queries receive NXDOMAIN. 3. Ideally: rejects queries with unexpected subdomain depth for allowlisted zones (e.g. rejects `<encoded>.api.anthropic.com` — anthropic's zone has no legitimate deep subdomains). The network egress guard research doc (`docs/research/network-egress-guard.md`) covers this under "Approach 4: DNS-based egress control" and notes it pairs with the in-container iptables approach. ## Scope - Add a dnsmasq (or CoreDNS) sidecar or in-container resolver. - Generate its allowlist from the bottle manifest's `egress.routes` host list. - Block outbound UDP/TCP 53 to non-local resolvers via iptables. - Document the residual gap: an agent that controls a subdomain of an allowlisted zone could still exfiltrate through forwarded queries (see research doc). ## References - `docs/research/network-egress-guard.md` — Approach 4 - `docs/research/secret-exfil-tripwire-encodings.md` — DNS exfil discussion - PRD 0053 (HTTP-level hostname scan — partial mitigation only)

didericis-claude commented

2026-06-06 14:14:17 -04:00

Note: this is not an issue for the smolmachines backend.

smolmachines uses TSI (Transport Socket Interface) — VMM-level connect() interception — which blocks all socket connections to non-allowlisted IPs before any bytes leave the guest. Since no DNS resolver is in the allowlist, DNS queries are blocked by construction, with no iptables required.

This issue is Docker-backend-specific: Docker's embedded DNS resolver at 127.0.0.11 is reachable from every container (including those on --internal networks) via NAT rules Docker installs at the host level. Blocking it from inside the container requires NET_ADMIN.

Plan: once the Docker backend is converted to an example/reference implementation and the smolmachines backend becomes the default, this issue will be closed. The Docker backend will be disabled (not the default), so this gap will not affect production deployments.

**Note: this is not an issue for the smolmachines backend.** smolmachines uses TSI (Transport Socket Interface) — VMM-level `connect()` interception — which blocks all socket connections to non-allowlisted IPs before any bytes leave the guest. Since no DNS resolver is in the allowlist, DNS queries are blocked by construction, with no iptables required. This issue is Docker-backend-specific: Docker's embedded DNS resolver at `127.0.0.11` is reachable from every container (including those on `--internal` networks) via NAT rules Docker installs at the host level. Blocking it from inside the container requires `NET_ADMIN`. Plan: once the Docker backend is converted to an example/reference implementation and the smolmachines backend becomes the default, this issue will be closed. The Docker backend will be disabled (not the default), so this gap will not affect production deployments.

didericis added the Kind/Security label 2026-06-06 14:14:51 -04:00

didericis-claude changed title from ~~DNS sinkhole: block raw DNS exfiltration via controlled resolver~~ to Promote smolmachines to default backend; convert Docker backend to example-only (resolves DNS sinkhole gap)

2026-06-06 14:46:19 -04:00

didericis-claude referenced a pull request that will close this issue

2026-06-06 16:03:31 -04:00

PRD: Promote smolmachines to default backend; convert Docker to example-only #210

didericis closed this issue

2026-06-08 23:34:53 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: didericis/bot-bottle#206