[Bug]: DNS Resolution Fails in Containers When a Local Service Binds to Port 53 on Specific Interfaces

[samurai00]

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. On the macOS host, configure and run a local DNS service like dnsmasq.
2. Crucially, configure this service to listen on port 53, but only on specific interfaces (e.g., lo0 at 127.0.0.1:53 and en0 at 192.168.24.39:53). It should not be listening on all interfaces (*:53).
3. Start the apple/container environment.
4. Attempt to resolve an external domain from within a container.
5. Alternatively, try to build an image that requires network access during the build process.

Current behavior

DNS resolution inside the container fails. The container's default DNS server, 192.168.64.1, is unreachable.

For instance, running nslookup inside a container results in a connection timeout:

$ container run --rm -i -t alpine:latest nslookup www.apple.com
nslookup: read: Connection refused
nslookup: read: Connection refused
;; connection timed out; no servers could be reached

Additional Context

$ ifconfig bridge103
bridge103: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
        ...

• The Conflict: The root cause is a port binding conflict. My dnsmasq service listens only on specific interfaces (e.g., 127.0.0.1:53).
• The Proof: The issue is resolved 100% of the time by stopping my dnsmasq service. When it's off, apple/container successfully uses the host's mDNSResponder to bind *:53 and provide working DNS to containers.
• The Hypothesis: The container's DNS proxy (via mDNSResponder) attempts a global bind to *:53. This fails if port 53 is already in use on any interface, preventing the DNS service for the container network gateway (192.168.64.1) from starting.

Expected behavior

• DNS resolution inside the container should work correctly using the default 192.168.64.1 resolver.
• The presence of another service on the host listening on 127.0.0.1:53 or 192.168.24.39:53 should not interfere with the container's DNS functionality.

Environment

- OS: macOS 15.6
- Xcode: Version 16.4 (16F6)
- Container: container CLI version 0.3.0 (build: release, commit: 3fcf647)

Relevant log output

Code of Conduct

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

[jglogan]

@Samaurai If this hypothesis were true, what would you expect the output of lsof -i :53 to be?

I see nothing listening there on my system.

With a container in that state that has curl on it, can you curl the IP address of any website?

Can you reproduce this issue on Tahoe?

The reason I ask all this is that, given you provided a bridge103 (you possibly are running three other NAT bridges), this feels like you could be hitting a network configuration issue in container due to macOS Sequoia.

[samurai00]

@jglogan Thanks for your reply.

Here are the results.

Scenario 1: When dnsmasq is NOT running (port :53 is not occupied by it)

When a container is running (e.g., the builder)

When a container starts, mDNSResponder on the host binds to port 53.

$ container ls -a
ID        IMAGE                                               OS     ARCH   STATE    ADDR
buildkit  ghcr.io/apple/container-builder-shim/builder:0.6.0  linux  arm64  running  192.168.64.2

$ sudo lsof -i :53
COMMAND   PID           USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
mDNSRespo 635 _mdnsresponder   76u  IPv4 0xd6055169509b3005      0t0  UDP *:domain
mDNSRespo 635 _mdnsresponder   77u  IPv6 0x782e2aa0f6bc540f      0t0  UDP *:domain
mDNSRespo 635 _mdnsresponder   78u  IPv4 0xf9e29861422427a8      0t0  TCP *:domain (LISTEN)
mDNSRespo 635 _mdnsresponder   79u  IPv6 0x99fb989c9e462c10      0t0  TCP *:domain (LISTEN)

In this state, curl from within a container works correctly and can resolve hostnames.

$ container run --rm -i -t curl-alpine curl -v http://www.apple.com/library/test/success.html
* Host www.apple.com:80 was resolved.
* IPv4: 221.194.154.187
*   Trying 221.194.154.187:80...
* Connected to www.apple.com (221.194.154.187) port 80
... (Success) ...
< HTTP/1.1 200 OK
...
* Connection #0 to host www.apple.com left intact

When no containers are running

If no containers are active, nothing is listening on port 53.

$ container ls -a
ID        IMAGE                                               OS     ARCH   STATE    ADDR
buildkit  ghcr.io/apple/container-builder-shim/builder:0.6.0  linux  arm64  stopped

$ sudo lsof -i :53
# No output

---

Scenario 2: When dnsmasq IS running (port :53 is occupied by it)

I start dnsmasq first, which binds to localhost:53.

When a container is running

lsof shows both dnsmasq (on localhost) and mDNSResponder (on IPv6) are listening on port 53.

$ sudo lsof -i :53
COMMAND     PID           USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
mDNSRespo   635 _mdnsresponder   61u  IPv6 0xa9ca876dd1a33f0f      0t0  UDP *:domain
mDNSRespo   635 _mdnsresponder   72u  IPv6 0x673cfc4544cf6184      0t0  TCP *:domain (LISTEN)
dnsmasq   39628         nobody    4u  IPv4   0xd7f042964cc89a      0t0  UDP localhost:domain
dnsmasq   39628         nobody    5u  IPv4 0x18384d5f691e2960      0t0  TCP localhost:domain (LISTEN)

When no containers are running

Only dnsmasq is listening on localhost:53.

$ sudo lsof -i :53
COMMAND   PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
dnsmasq 39628 nobody    4u  IPv4   0xd7f042964cc89a      0t0  UDP localhost:domain
dnsmasq 39628 nobody    5u  IPv4 0x18384d5f691e2960      0t0  TCP localhost:domain (LISTEN)

In this state, curl from within a container fails to resolve the host.

$ container run --rm -i -t curl-alpine curl -v http://www.apple.com/library/test/success.html
* Could not resolve host: www.apple.com
* shutting down connection #0
curl: (6) Could not resolve host: www.apple.com

---

Regarding bridge100

I also tried disabling all other software that might create bridge10X interfaces. The behavior remains exactly the same as described above. The primary interface used by the container framework appears to be bridge100. Here is its configuration:

$ ifconfig bridge100
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        options=63<RXCSUM,TXCSUM,TSO4,TSO6>
        ether ...
        inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
        inet6 ... prefixlen 64 scopeid 0x1b
        inet6 ... prefixlen 64 autoconf secured
        Configuration:
                id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
                maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
                root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
                ipfilter disabled flags 0x0
        member: vmenet0 flags=10803<LEARNING,DISCOVER,PRIVATE,CSUM>
                ifmaxaddr 0 port 26 priority 0 path cost 0
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active

[jglogan]

Ah, I neglected to sudo for lsof. I can reproduce what you see.

What are you trying to achieve with dnsmasq? This is certainly not a container issue; it has to do with what macOS is doing upstream of container. I'm wondering whether there's a way to configure things differently to achieve your objective.

[samurai00]

My use case for dnsmasq:

1. Local Development & Testing: I use it to resolve custom local domains (e.g., project.dev) and override specific public DNS records for testing purposes. This is a common developer workflow.
2. Home Network DNS Server: My Mac also acts as the primary DNS server for my entire home LAN. This allows me to provide network-wide features like custom internal hostnames for my devices.

I'm not sure if this is helpful, but I wanted to share an observation from another tool. When I run the exact same dnsmasq setup, OrbStack works without any conflict. I looked into its container's DNS configuration, and /etc/resolv.conf shows the following:

# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 0.250.250.200

# Based on host file: '/etc/resolv.conf' (legacy)
# Overrides: []

Of course, I understand their architecture is likely very different. However, this suggests they use a DNS proxy on a special, non-conflicting IP address rather than binding to a host-level IP on the standard port 53. It demonstrates that a solution to coexist with local DNS services is achievable on macOS.

[nafees-anwar]

I am having a similar issue when using Cloudflare WARP.

Scenario # 1

• Run any container.
• mDNSResponder occupies port 53.
• WARP can no longer start.

Scenario # 2

• Turn on WARP
• WARP starts a local DNS server on port 53 on the loopback interface.
• Start a container.
• DNS resolution fails inside the container.

[jglogan]

@nafeesanwar this is the same root cause - you can't have two listeners on the same interface and port. Only one or the other can run.

This isn't a container or containerization issue, it's an effect of how macOS works with any virtualization solution and how WARP works; see https://www.arayofcode.com/posts/mdnsresponder/.

Could you start a separate issue for this? For dnsmasq I'd like to investigate whether the configuration can be tweaked to resolve the issue. For WARP we'll likely need a different approach.

[nafees-anwar]

@jglogan, yes, I understand you can't have two listeners on the same interface and port. But I believe the 2nd scenario I mentioned, where WARP is already running and DNS resolution fails inside the container, is the same as the dnsmasq. Hopefully, resolving this issue will fix it for all local DNS servers.

[byjrack]

I know this is a blocker for us to look at using Containers as it fights with our VPN so wondering if there is any way for me to nudge mDNS out of a global UDP/53 bind?

Currently I can use --dns to override the mdns resolver with an static internal DNS server, but like to reduce some of the hard coding long term.

Just hoping that this scenario is a bit higher up the stack for resolution.