[Bug]: leftover /etc/resolver/containerization.* 'search' directive hangs ALL bare-hostname DNS lookups system-wide once apiserver stops #1917

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

1. Follow the container DNS tutorial, e.g. sudo container system dns create test, then run a container and resolve it via <name>.test (see /etc/resolver/containerization.test created as described in [Bug]: Wrong DNS resolver filename theory — not a bug, closed #1407).
2. Stop the container system entirely: container system stop (or just let the apiserver not be running, e.g. after a reboot before starting it again).
3. Do not remove /etc/resolver/containerization.test — it is left in place.
4. From the host, resolve any bare, unqualified hostname unrelated to containers at all, e.g. one handled by a VPN's split-DNS (in my case a Tailscale MagicDNS short name), or any LAN hostname:

   time dscacheutil -q host -a name some-other-host
   

Problem description

/etc/resolver/containerization.test (created by the DNS tutorial / container system dns create) contains:

domain test
search test
nameserver 127.0.0.1
port 2053

The search test directive adds test to macOS's system-wide search-domain list — the list used to expand any unqualified single-label hostname, not just ones ending in .test. This is independent of the containerization.test filename-vs-domain mismatch already reported in #1407.

The practical effect: once the container apiserver is not running (stopped, or simply not yet started after boot), 127.0.0.1:2053 has nothing listening. Every bare hostname lookup on the Mac — SSH to a Tailscale MagicDNS short name, a LAN device, anything with no dot in it — now also gets tried as <name>.test against that dead nameserver as part of normal search-domain expansion, and that query hangs (no ICMP unreachable, no fast refusal) rather than failing quickly. Observed delay: consistently ~10 seconds per bare-hostname lookup, which is enough to make unrelated tools (ssh, ping, etc.) appear to hang system-wide.

This makes the resolver file dangerous to leave behind: the "harmless" tutorial artifact silently degrades unrelated DNS resolution for the entire machine as soon as the container apiserver stops, until the file is manually deleted (sudo rm /etc/resolver/containerization.test) and there's no message/warning to that effect.

Expected behavior

Either:

• container system dns create <domain> should not use a global search directive at all — /etc/resolver files should only need domain/nameserver/port to scope matching by filename per resolver(5), without contributing to the system-wide search list, or
• The resolver file (and its search contamination) should be automatically removed when container system stop runs / the apiserver is not registered with launchd, or
• At minimum, container system status / container system stop should warn if a stale /etc/resolver/* file exists pointing at a now-unreachable local port, since its side effects extend well beyond container networking.

Environment

- OS: macOS 26.5.2
- Container: 1.1.0

Code of Conduct

• I agree to follow this project's Code of Conduct