[Request]: First-class container-to-container DNS discovery on custom networks

[thromel]

Feature or enhancement request details

Please add first-class container-to-container DNS discovery for containers attached to the same container network, including bare container names and network aliases.

This came up while testing Compose-compatible workflows with container-compose. Compose users expect service names such as web, db, and network aliases to resolve from peer containers on the same network without a global host DNS setup step.

Related tracking:

• Existing DNS bug/discussion: [Bug]: internal DNS does not work (clean install) #856
• Compose compatibility tracker: Track Compose compatibility gaps found with apple/container 1.0.0 Mcrich23/Container-Compose#118
• Container-Compose service discovery issue: Services on the same Compose network cannot resolve service names Mcrich23/Container-Compose#114
• Container-Compose network aliases issue: Parse Compose service network object form for aliases Mcrich23/Container-Compose#116

Current behavior on container 1.0.0:

container system start
container network create appnet
container run -d --name network-web --network appnet nginx:alpine
container run --rm --network appnet busybox:latest nslookup network-web

The peer container receives the network gateway as its resolver:

container exec network-web cat /etc/resolv.conf
# nameserver 192.168.65.1

The container is reachable by IP from the same network, but name lookup returns NXDOMAIN:

Server:         192.168.65.1
Address:        192.168.65.1:53

** server can't find network-web: NXDOMAIN

The currently documented workaround appears to be configuring a DNS domain with container system dns create <domain> plus setting dns.domain. That can make FQDN/search-domain flows work, but it is not the same as network-scoped, Compose-style service discovery. It also requires global host DNS configuration for what is usually expected to be a per-network container runtime feature.

A useful end state would be one of these:

1. Containers on the same network can resolve each other by container name, for example web -> that container's network IP.
2. The network layer supports additional network-scoped aliases so higher-level tools can map Compose service names and aliases onto Apple Container networks.
3. If bare names are intentionally out of scope, expose a supported CLI/API path that tools can use to create network-scoped DNS domains/aliases without requiring users to manually toggle global DNS settings.

Environment used for the repro:

- OS: macOS 26.5.1 (25F80)
- Xcode: 26.5 (17F42)
- Container: container CLI version 1.0.0 (build: release, commit: ee848e3)
- Architecture: arm64

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

[thromel]

Update: I opened a draft implementation PR for the container-facing DNS part:

• Add DNS forwarding groundwork #1813

What it covers:

• containers can query their vmnet gateway on UDP port 53
• responses are scoped to source IPs inside active container networks
• bare container hostnames resolve through the existing network service
• external names are forwarded to upstream DNS servers so the listener does not break normal container DNS

The PR is intentionally draft/RFC because it binds wildcard UDP 53 and currently discovers upstreams from /etc/resolv.conf; both are design choices that should get maintainer review.

It is stacked on #1810 because the DNS path needs the hostname normalization/trailing-dot behavior from that PR.

Remaining work for Compose-style parity: explicit network aliases/service aliases still need API/CLI support after the bare-hostname DNS path is settled.

[thromel]

Follow-up draft PR for explicit aliases is open:

• Add network attachment aliases #1815

This stacks on #1813 and adds a narrow alias registration path:

• AttachmentOptions / Attachment carry aliases
• --network backend,alias=db,alias=database parses repeated aliases
• network allocation registers aliases as additional DNS names for the same address
• releasing the attachment removes the primary hostname and aliases together
• container creation checks aliases for duplicate-name conflicts

I could not complete live alias validation because the local debug apiserver launch did not become healthy during the smoke-test attempt. Unit/build coverage is included in the PR body, and the installed /usr/local service was restored afterward.

[thromel]

Status update:

• Add DNS forwarding groundwork #1813 is now marked ready for review. It includes the container-facing DNS listener, standard DNS query validation, source-network scoping, upstream forwarding, and invalid/loopback upstream filtering.
• Add network attachment aliases #1815 has been rebased on top of the updated Add DNS forwarding groundwork #1813 stack and now includes additional coverage for alias serialization compatibility and client attachment-option plumbing.
• Add network attachment aliases #1815 remains draft because live alias smoke validation is still blocked by the local debug apiserver launch issue described in the PR body. The in-process parser/allocator/resource/client coverage passes, and the installed /usr/local release service was restored after the smoke attempt.

[thromel]

Status update: #1815 is now ready for review.

I was able to complete live alias validation by staging the debug build into a temporary install root and starting the service with explicit --install-root/--log-root settings.

Validated behavior:

• container run --network codex-alias-live,alias=db,alias=database ... registers both aliases
• peer containers on the same network resolve db, database, and the primary container name through the network gateway DNS
• a duplicate alias=db attachment fails with the expected duplicate-hostname error
• test containers/networks were removed afterward
• the installed /usr/local release service was restored and verified healthy