[Bug]: Wrong DNS resolver filename theory — not a bug, closed

[x8x]

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. sudo container system dns create vm
2. container system property set dns.domain vm
3. container run -d --name nginx nginx:latest
4. curl http://nginx.vm

Problem description

container system dns create vm creates the resolver file as /etc/resolver/containerization.vm instead of /etc/resolver/vm:

$ ls /etc/resolver/
containerization.vm

$ cat /etc/resolver/containerization.vm
domain vm
search vm
nameserver 127.0.0.1
port 2053

macOS dispatches DNS queries based on the resolver filename (resolver(5)), not the domain directive inside the file. A query for nginx.vm matches /etc/resolver/vm — which doesn't exist. The containerization.vm file only catches *.containerization.vm queries.

The container's embedded DNS server works correctly when queried directly:

$ dig @127.0.0.1 -p 2053 nginx.vm
;; ANSWER SECTION:
nginx.vm.		5	IN	A	10.0.4.22

The expected behavior is that container system dns create vm creates /etc/resolver/vm, so <name>.vm resolves from the host — matching what docs/tutorial.md describes.

Workaround: sudo cp /etc/resolver/containerization.vm /etc/resolver/vm

If the containerization. prefix is intentional namespacing, the docs should reflect the actual hostname format, or the CLI should also create /etc/resolver/<domain>.

Environment

- OS: macOS 26.4
- Xcode: 26.4
- Container: 0.11.0

Code of Conduct

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

[vxnkjyffmq-code]

Yes thank you

[jglogan]

@x8x

macOS dispatches DNS queries based on the resolver filename (resolver(5)), not the domain directive inside the file. A query for nginx.vm matches /etc/resolver/vm — which doesn't exist. The containerization.vm file only catches *.containerization.vm queries.

If you create the vm domain and don't do your workaround, what do you see for scutil --dns for the scoped domain?

I see:

 % container system dns ls
DOMAIN
test

% cat /etc/resolver/containerization.test 
domain test
search test
nameserver 127.0.0.1
port 2053

% scutil --dns | grep -B 1 -A 5 'domain *: *test'
resolver #11
  domain   : test
  search domain[0] : test
  nameserver[0] : 127.0.0.1
  port     : 2053
  flags    : Request A records, Request AAAA records
  reach    : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

This contradicts your assertion that "macOS dispatches DNS queries based on the resolver filename (resolver(5)), not the domain directive inside the file."

The fact that yours is the first complaint to this effect after almost a year is another data point.

Could you show me the part of the man 5 resolver output that states that the filename has a semantic purpose? All I can find in my version of macOS is:

     The configuration for a particular client may be read from a file having the format described in this man page.  These are at present located by the system in the /etc/resolv.conf file and in the files found in the /etc/resolver directory.
     However, client configurations are not limited to file storage.  The implementation of the DNS multi-client search strategy may also locate client configuratins in other data sources, such as the System Configuration Database.  Users of the DNS
     system should make no assumptions about the source of the configuration data.

[x8x]

@jglogan You were right. I re-read man 5 resolver in full — the domain directive inside the file takes absolute priority over the filename.

The root cause on my end was a stale manual edit to /etc/resolver/containerization.vm I'd made almost a year ago while trying to get container's DNS working alongside a local resolver — the same conflict described in #402 — and I completely overlooked it. When my tests started succeeding after I copied the file, I attributed the fix to the rename — but the real fix was a container system dns delete vm && container system dns create vm I'd run a couple of steps earlier, which had already replaced the stale file with a fresh one.

Apologies for the noise. Closing.