The platform's DNS service for sandboxes (029 T015, 029-FR-013, 029-FR-012, 029-FR-015).

Why a sandbox needs one at all

FR-013's own text calls a working DNS story "a precondition for FR-012 rather than a separate nicety", and it is right in a stronger sense than it reads. Two independent things both stop without it:

• T011's ruling made DNS the only permitted UDP destination. The inet filter output chain ends in a terminal meta l4proto udp drop, so until something names a resolver, a sandbox sends no UDP at all — DNS is off, not permissive.
• FR-012 matches a hostname entry against what this sandbox resolved that name to. Something has to have done the resolving, and it has to be the platform, because the whole point is that the tenant does not get to decide what its own allowlist means.

So this module is both halves: it answers the query, and the act of answering is what files the name→address binding the verdict later consults. Those are deliberately the same event. A design where resolution and recording are two steps has a state in which a sandbox has an answer the platform did not record — and a tenant that reaches that state connects to an address no entry can match, which reads as a broken allowlist.

Mechanism-neutral, and what that costs

⚠️ Written mechanism-neutral from the first line (D27's transfer column). Nothing here knows about pasta, network namespaces, nft, or bwrap. It receives DNS query bytes and a source key, and returns DNS response bytes. A second mechanism supplies the same two things by whatever route it has and reuses this untouched.

What that costs is a transport, and the transport is the same one the verdict socket already uses and for the same reason: a network namespace isolates the network stack, not the filesystem, so an AF_UNIX socket on a host path is reachable from inside a sandbox's netns while being invisible to the tenant, which bwrap never binds into its mount view. See ExSandbox.Egress.Verdict for the measurement.

⚠️ The listener that carries datagrams to this socket runs inside the namespace (nsacceptor.py), for the identical reason the TCP acceptor does: a socket's network namespace is fixed by the namespace of the calling process, and the BEAM never enters the sandbox's.

Every answer passes the same structural filter as every entry

⚠️ This is the hole FR-012 opens, closed in the same module that opens it. Name matching means a tenant who controls a DNS record for a name in their own allowlist can point it at 127.0.0.1 — and every parse-time test stays green while they do it. spec.md calls this "the sharpest concrete instance of this spec's own thesis".

So every address this module is about to record is first put through ExSandbox.Egress.Allowlist.classify/2 — the same classifier the written entries go through, not a second copy. A refused answer is dropped from the record and from the response, so:

• the tenant never learns the address from us, and
• the address is not in the record, so a connect to it matches no entry and is refused by Policy at connect time,

and the refusal names the same class (:loopback, :rfc1918_private, …) a written entry would have been refused for.

⚠️ Dropping the answer rather than refusing the query is deliberate. A SERVFAIL would tell the tenant which of its names the platform declines to resolve, and more importantly it would make a rebinding attempt look like an outage. An A record set with the excluded members removed is the honest answer to "which of these may this sandbox be told about?".

Answers accumulate; they do not replace

A name that resolves into a rotation gives a different member on each query, and a connection opened against the first answer while the second is being recorded must not be refused for it. ExSandbox.Egress.Registry.record_resolution/4 unions. The set is bounded by the sandbox's own lifetime, because it lives in the registry entry that Binding.release/2 deletes.

What this module deliberately does not do

It does not decide anything. Policy decides; this records. And it does not resolve on the verdict path — a resolution performed at connect time on the platform's behalf would compare the tenant's connection against an answer the tenant never received.