DNS issues in user-defined docker networks

[cmainas]

The DNS resolution for urunc-based containers which start in a user-defined network of docker does not work. To reproduce the issue:

1. Create a new network in docker.

$ sudo docker network create -d bridge my-bridge-network
74bc6ad05c22bdec6267fe95d27b3c3ac13be3bda89c73463890068893bbbaff

2. Start a urunc container in this network:

$ sudo docker run --rm --network my-bridge-network -it --runtime io.containerd.urunc.v2 harbor.nbfc.io/nubificus/urunc/busybox-qemu-linux-raw:latest

3. From inside the container try to resolve any domain:

# nslookup github.com
nslookup: write to '127.0.0.11': Connection refused
;; connection timed out; no servers could be reached

As shown from nslookup, the DNS request goes to 127.0.0.11. Also the /etc/resolv.conf of the container:

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

nameserver 127.0.0.11
...

This happens because docker sets up an internal DNS server which listens at localhost for each container inside the network namespace (See https://docs.docker.com/engine/network/#dns-services). Therefore, when docker sets the localhost as a DNS server in /etc/resolv.conf, a urunc based container does not communicate with the localhost of the network namespace in the host, but with the localhost inside the sandbox and hence the request fails.

[praffq-dev]

@cmainas can you please assign this to me. I'll like to work on it. Thanks!

[cmainas]

Hello @praffq-dev ,

this issue is a candidate as a project for CNCF's mentorship program. Therefore, we will not assign it to anyone for the time being.

[praffq-dev]

Ah ohkay , understood! Thanks.

[ishaanxgupta]

I think the root cause is the mismatch between Docker’s embedded DNS model and urunc’s sandbox/VM network model.
For containers attached to a user-defined Docker network, Docker writes:nameserver 127.0.0.11 to /etc/resolv.conf. This works for normal runc containers because Docker’s embedded DNS server is reachable from the container network namespace loopback. With urunc, the workload runs inside a sandbox/VM guest. So 127.0.0.11 points to the guest loopback, not to Docker’s DNS listener in the host/container network namespace. The DNS packet never reaches Docker’s embedded DNS server, so resolution fails with Connection refused.

urunc’s current network path creates a TAP device and redirects traffic between Docker’s veth and the guest, but it does not handle loopback-only services from the outer network namespace. This affects Docker DNS specifically.

Possible fixes:

• Detect nameserver 127.0.0.11 in the generated /etc/resolv.conf and rewrite it before booting the guest.
• For external DNS only, rewrite it to the host/upstream DNS servers.
• For full Docker user-defined network semantics, add a small DNS proxy in the container network namespace, reachable from the guest through the TAP/veth path, and forward requests to Docker’s 127.0.0.11.
• Add an e2e test using docker network create, a urunc Linux guest, and nslookup github.com.
• Also test container-name resolution inside the same Docker network, because simply replacing 127.0.0.11 with public DNS would fix external domains but break Docker service discovery.