The outbound seam: one door out of valis

getaddrinfo speaks no protocol of its own. It dispatches through the hosts: line of /etc/nsswitch.conf to loadable name service switch modules, and which modules are consulted is configuration the process neither chooses nor can read out of its own source.

A serving valis runs inside a network namespace, and that is where this stops being trivia. Such a process can hold working sockets, a correct routing table and a reachable nameserver and still resolve nothing at all, because the hosts: line it inherited, names a module that cannot answer from where it is standing. Every layer above reports that as though the name did not exist.

The rule that follows, for anyone adding an outbound path: a library that implements DNS itself, rather than asking the system, opts out of the one lever an operator holds over a confined node. It does so silently, and only on a deployed host.

SBCL's own socket layer hands a lookup to glibc getaddrinfo, so it goes through the switch and obeys the confined view. iolib, which this seam uses for its sockets and never for names, carries a DNS client of its own: it reads /etc/resolv.conf itself, opens its own datagram socket, and sends the query. Inside a namespace whose nameserver that client cannot reach, it fails on the query socket rather than in the resolver, so what surfaces is a condition about polling a descriptor.

That failure is also defined outside its own library's condition hierarchy, so it is neither a resolver condition nor a socket condition. It escapes the library's retry path and it escapes a lookup that was asked not to signal. The general form outlives this one library: a condition class outside a hierarchy escapes every handler written for that hierarchy, and a handler broad enough to catch it anyway is one that cannot discriminate.

None of this is a preference between libraries. It is measured behaviour on a confined node, and it is the defect that produced this seam.

The namespace launcher, ip netns exec, bind-mounts /etc/netns/<name>/* over the matching files in /etc for the process it starts. That is the supported way to hand a confined process a different resolv.conf or a different nsswitch.conf, and it works under a hardened service unit with a strict read-only system, a private temporary directory and a full capability bounding set, with both files binding.

The pitfall is silent. A bind that fails prints one line to standard error and still exits zero. The unit reports success while the process runs on the host's configuration instead of the one written for it. Anything depending on that view must assert the bind took effect and must never infer it from an exit status.

This is measured rather than inferred from a manual page. It was run under a unit carrying exactly those restrictions on two systems four systemd releases apart: the deployment platform, Debian 13 with systemd 257 and iproute2 6.15, and a development workstation running systemd 261 and iproute2 7.1. On both, the file placed under /etc/netns was what the confined process read, and standard error, read on its own, carried the unit's ordinary reporting and no failed bind. A file whose contents cannot be read back leaves only the second of those checks, which is why it is worth capturing separately.

Under AI_ADDRCONFIG, which is the ordinary default, the system declines to look up a family the local machine holds no configured address of, and it declines before any query leaves. The failure is EAI_NONAME, rendered "Name or service not known": exactly what a name that exists nowhere produces, and exactly how an NXDOMAIN from a nameserver arrives.

Since the answer cannot separate them, the seam asks the kernel a different question instead of asking the network again. It opens a datagram socket of the family and fixes its peer at an address reserved for documentation: TEST-NET-1 for version four (192.0.2.1) and the documentation prefix for version six (2001:db8::1). Fixing a datagram socket's peer transmits nothing. It performs a route lookup and, where one succeeds, binds a local source address that can be read back. So the question actually asked is whether this namespace holds a routable address of that family, the answer costs one socket and no packets, and the reserved destination means even a misreading of that code cannot put traffic on a wire toward a real host.

A network namespace partitions interfaces, routes and ports. It does not partition the mount namespace, so a pathname AF_UNIX socket is reachable from inside one by path exactly as it is from outside.

That is how a node reaches its own operator-state database over a unix socket with no TCP listener anywhere and no password on any wire. It is also why AF_LOCAL connections sit outside this seam's remit: they never leave the host, so there is no destination to decide about and no name to look up. The refusing check beneath the socket libraries makes the same exclusion for the same reason.

The paragraph above is true and it is not the whole picture. A reader who stops there takes away that the crossing is a convenience. It is also the one path out of a confined namespace that this seam never sees, and on a stock systemd host it is open by default.

On such a host the hosts: line consults nss-resolve, which does not send a query. It asks systemd-resolved over the pathname socket /run/systemd/resolve/io.systemd.Resolve, and that socket is mode srw-rw-rw-. Any user id inside the namespace can drive host-side resolution through it, for any name, and the namespace's own egress policy is never consulted because nothing the policy governs is used.

Measured on a development workstation on 2026-07-27, and it is blunter than the description. A namespace holding no configured interfaces at all resolves a public name successfully:

unshare -Urn getent hosts example.com   -> 2606:4700:10::ac42:93f3, rc=0

The control isolates the cause. Same namespace, plus a private mount namespace and a tmpfs laid over the socket directory:

unshare -Urnm sh -c 'mount -t tmpfs none /run/systemd/resolve; getent hosts example.com'
                                        -> no output, rc=2

Why this belongs in a document about the outbound seam: the confinement argument for hosting code the operator did not write is that such code has nowhere to send anything, because every destination has to be presented to one verb first. A query name is attacker-chosen text that reaches the network. Low bandwidth is not no bandwidth, and exfiltration over query names is old, well understood work.

Two further points a reader should not have to rediscover. This is not specific to the seam's own libraries: it is glibc's switch, so it holds for anything in the namespace that resolves names the ordinary way, whatever language it is written in. And it should not be read as a defect awaiting an upstream fix. systemd-resolved.service(8) places the stub on loopback addresses in a single namespace and describes no per-namespace operation anywhere, so a host resolver reached from several namespaces at once is a configuration outside what the service sets out to do. Closing this is our decision to make, on our side of the boundary.

The disposition today is open, and stated rather than mitigated. What would close it is visible in the control above: masking the socket directory inside the unit's mount namespace. The cost is that the confined process then resolves nothing at all, so the name path it is supposed to use has to be put somewhere before that mask goes on, which makes this a decision about the namespace's resolver rather than a flag to set.

Every Lisp source under src/ is read with its comments and string contents removed, and a source naming a verb that dials or resolves fails unless the exemption registry names it. The sweep walks the tree and the registry is the set of exceptions taken out of it, never the other way round. A scan over a written-down list of files checks only the files somebody thought of, and a subsystem added tomorrow goes unchecked while saying nothing about it.

The count of files read is asserted to clear a floor, because a walker that found nothing would satisfy every other assertion and read as a clean run.

Prose may name any of these verbs freely. The writing that explains why a file must not call something is exactly the writing that names it, so a sweep punishing prose would be weakened until it checked nothing.

A source sweep is blind to two things: a library valis merely loads, and a call reached through a symbol rather than written as one. Both are real. So a running node installs a check beneath the socket libraries' own connect verbs. Its decision, cheapest first: the seam's own connection proceeds; a connection in the local address family proceeds; otherwise the stack is walked for the innermost frame outside the socket libraries, and a name on the escape list proceeds and is counted. Anything else, including a caller that could not be named, is refused.

The check holds no way of turning a name into an address, and a test reads the file as code to keep it that way. A resolving check would rebuild the very verb this seam does not have, one layer below where it was forbidden.

The node installs the check when it starts and removes it when it stops, and a test compares both definitions by identity across a start and stop cycle.

src/net/exemptions.lisp is one list with two fields: a repo-relative path for the source sweep, and a package-qualified function name for the run-time check. They are one subject seen from two angles, and kept as two lists they drift.

Entries are marked :by-design or :migration-debt. The debt entries exist in order to be removed, and four things hold the list open, because intending to empty it is what failed the last time this was tried:

• every entry carries a full sentence saying why, not a tag;
• a test compares the whole list against a written-down expected value, so growth fails until someone edits the expectation on purpose;
• a runtime report leads with the count of what remains unmigrated, so it can be read off a running node rather than inferred by reading code;
• every entry naming a caller counts the connections it was let through on, so an entry nothing uses is visibly deletable and one used constantly is visibly urgent. A zero is printed rather than withheld.

What it costs when an entry is wrong is worth being blunt about, because it has already happened twice here. The check reads the site a connection was opened from. Two entries named the valis-side function that asks for a connection rather than the one that opens it, not because of any malice on my part but because the knowledge of the function was in my mind and my internal flow state reached for it logically within the procedure I was encoding, just one frame deeper and in a sibling system. I didn't even notice doing this when it happened. A name the check can never match is decorative, which is the one thing an exemption list must not be. Both were corrected once the running node was measured in QA, rather than read.

The failure direction of a wrong entry matters and is deliberate: an unmatched or unnameable caller is refused, never permitted. A wrong entry therefore breaks a path loudly instead of opening one quietly. The exception is an entry naming something too broad. Widening an entry to name a third-party HTTP client, for instance, would permit every caller that client has, which is a wildcard by another name.

• One debt entry is knowingly unmatchable. That path reaches an HTTP client by symbol at run time, and the client opens the connection itself, so the check names the client rather than the site that called it. The path is refused. The entry keeps the site the migration has to reach rather than being widened to the client.
• Two permanent entries name sites the check never reaches, because they are in the local address family and the local-family rule short-circuits before the stack walk. They are not wrong; they are simply never consulted. If either ever moves off AF_LOCAL, its name should be measured rather than assumed.

Do not add a loopback exception to the local-family rule. It would let any library in the image reach any local service, including a proxy that forwards off-host . Where a local destination genuinely needs permitting, the check belongs in that subsystem: the operator-state pool classifies the database host the operator configured and refuses one it would have to leave this node's own network to reach.

A person under stress reaches for whatever works now, and a warning read weeks earlier does not survive that state. So the design position is that a convenient path and a safe path must not look equivalent at the moment of use, and that a node should be able to state which mode it is running in rather than relying on anyone to remember what they chose.

What a node can state about itself today is what still reaches the network outside the seam. valis/src/net/exemptions:report-outbound-exemptions prints, on a running node: the count of sites still unmigrated, each one with what it is blocked on and how many connections it has been let through on since the counts were cleared, then the permanently permitted set with the same counts, then the one tracked tree of Lisp sources the sweep deliberately skips and why. It reads the escape counts off the live node, so it reports what has actually happened rather than what the source implies.

What does not exist yet, said plainly rather than implied: there is no client-facing indicator telling the person at the other end of a session which mode that session is running in, and no affordance making a convenience path visibly different from a hardened one at the moment of use. Both are design requirements of this seam and neither is built. Until they are, a reader in real danger should assume nothing about a session's protection from the fact that it worked.