[Request]: Add ability to connect to a host service

[zakhenry]

Feature or enhancement request details

Hopefully this is just a case of adding documentation?

With docker I can run a webserver locally on http://127.0.0.1:1420/ and run a container (e.g. mcr.microsoft.com/playwright:v1.45.3-noble) and connect to the server running locally from the container for the purposes of running tests against the local service.

With docker on macos I configure the url as http://host.docker.internal:1420 which works, I tried http://host.containers.internal:1420 & http://host.container.internal:1420 but get curl: (6) Could not resolve host: host.container.internal (my first command run in container is curl --fail --silent --show-error http://host.containers.internal:1420> /dev/null)

Interestingly the host.containers.internal fails instantly, and host.container.internal take 11 seconds before failing.

Is there some other magic hostname that I should use with containers? Potentially of note I am on Sequoia 15.5 so can't try out the new networking options.

Code of Conduct

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

[jglogan]

@zakhenry thanks!

This is a known limitation; see https://github.com/apple/container/blob/main/docs/technical-overview.md#container-to-host-networking for a workaround, but it's something we do want to get to, so we'll use your issue for tracking the work.

Making this work isn't too hard, until you need to make it usable across more than the default network which whenever container services are running. In terms of implementation approaches, one would be to:

1. Add a scoped DNS configuration that causes mDNSResponser to send queries for host.docker.internal to container (this sort of thing happens today when you run sudo container system dns create test).
2. Add a DNSHandler that resolves host.docker.internal to some dummy IP address, like something in the 172.16.0.0/20 block.
3. For each network, add a packet filter rule that redirects traffic from the network bridge to any port on the dummy address the corresponding port on 127.0.0.1 on the host.

The challenge that I see is that 1. and 3. require administrator privilege.

We could run a privileged helper for this but running a service this way requires a bit of attention to security, and it may not be acceptable in all environments.

For DNS we can limit the need for sudo to just creating the scoped resolver config in /etc/resolver, and HUPping mDNSResponder. It's not as simple for this, though, as networks come and go, so the user would need to be running sudo at both ends of a network's lifecycle. This isn't ideal for usability either.

[debasisdwivedy]

MAC OS: 26.0.1
Container version: container CLI version 0.6.0 (build: release, commit: a23bcf0)

I am getting an error related to this as well as below:

Running /bin/bootstrap.sh
failed to apply transformations: lookup host.docker.internal on 192.168.64.1:53: no such host

[jnoortheen]

I have tried to use the https://github.com/apple/container/blob/936c916916c1da2aa94f9e28ba010bf1b01e2c80/docs/technical-overview.md#container-to-host-networking socat workaround. It doesn't seem to work. Here is a small snippet to see what I was doing.

$ python3 -m http.server 8000 &
$ socat TCP-LISTEN:8000,fork,bind=192.168.64.1 TCP:127.0.0.1:8000 &
$ container run --rm -it curlimages/curl curl http://127.0.0.1:8000
curl: (7) Failed to connect to 127.0.0.1 port 8000 after 0 ms: Could not connect to server

[jglogan]

Assigned - I hope to have this tackled before the next release.

Proposal

This approach uses the existing container system dns command which already requires sudo.

The approach is secure since it does not allow configuration of forwarding to arbitrary IP addresses - all pf redirects target 127.0.0.1.

It supports the host.docker.internal case without requiring that the user use that name.

Proposed changes are:

• Use a custom resolv.conf option apple-container-localhost to indicate that a local domain should be treated
  • Format is apple-container-localhost:ip-addr, where ip-addr is a conflict IP address chosen by the user (for example, 203.0.113.113 from the TEST-NET-3 documentation range)
• Add a --localhost-ip ip-addr option to container system dns create that creates a domain that creates a /etc/resolvers file and reloads mDNSResponder as usual, but adds the apple-container-localhost option. The command then collects all such options from the container resolver files and uses them to create/update BSD packet filter rule that redirect those IPs to 127.0.0.1.
• On startup, collect all apple-container-localhost options from the container resolver files, and set up local DNS with handlers that resolve each domain to its corresponding IP address.
• Remove search line from DNS domain creation to address [Bug]: Investigate DNS search path / resolver priority improvements. #817 (macOS 26: Inconsistent short hostname resolution with MagicDNS tailscale/tailscale#17096).

[JaewonHur]

It's quite difficult to make ContainerDNSHandler to differently handle those queries for localhost.
Giving option in /etc/resolver/<XXX.com> makes no difference to the query forwarded from mDNSResolver to ContainerDNSHandler.

How about allocating another port (e.g., 1053) for which our DNS handler returns that ip-address if domain name matches.