Skip to content

DNS not working in user-defined network with IPv6 DNS servers #46329

@fansari

Description

@fansari

Description

When I use a customized network with IPv6 I noticed that DNS is not working. I could solve this by deactivating the 127.0.0.11 entry in the /etc/resolv.conf file - but this appears again after every restart of the container and I don't know how to get rid of this.

As far as I understood this is some internal DNS server which appears when you use a customized network.

To make sure the reason is not firewall issues I deactivated nftables and have "iptables": true set.

Here my /etc/docker/daemon.json:

{
  "ipv6": true,
  "fixed-cidr-v6": "2xxx:xxxx:xxxx:xxxx:xxxx::/80",
  "iptables": true,
  "dns": [ "2xxx:xxxx:xxxx:xxxx::aaaa", "2xxx:xxxx:xxxx:xxxx::bbbb" ]
}

When I use dns setting either from daemon.json or directly configured at the container after I start the container I cannot resolve addresses e.g. "dig @127.0.0.11 google.com" The addresss mentioned above appear in /etc/resolv.conf and if I resolve directly against them it is working. E.g. "dig @2XXX:xxxx:xxxx:xxxx::aaaa google.com" will work. But since the container is always trying to use the 127.0.0.11 the request is hanging. With tcpdump I see no outgoing traffic on the host. I also ran a tcpdump inside the container and find nothing on port 53.

When I remove the DNS entry from daemon.json the IPv6 DNS servers from Google will appear in /etc/resolv.conf. Resolution against 127.0.0.11 is working in this case - but this way we cannot resolve our internal addresses anymore from inside the container. I investigated this with tcpdump on the host and found that the outgoing traffic is not going to 2001:4860:4860::8888 but to 8.8.8.8.

Another thing I have tried is to configure the DNS with IPv4 addresses. The outcome was surprising: now these addresses do not appear in /etc/resolv.conf of the container but resolution works via 127.0.0.11 both for external and our internal addresses.

Reproduce

Explanations given above.

Expected behavior

DNS resolution against 127.0.0.11 should work or it should be possible to deactivate this internal server.

docker version

Client:
 Version:           20.10.23
 API version:       1.41
 Go version:        go1.20rc3
 Git commit:        %{shortcommit_cli}
 Built:             Sun Jan 29 17:25:05 2023
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.23
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.20rc3
  Git commit:       %{shortcommit_moby}
  Built:            Sun Jan 29 17:25:05 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.19
  GitCommit:
 runc:
  Version:          1.1.7
  GitCommit:
 docker-init:
  Version:          0.19.0
  GitCommit:

docker info

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 2
  Running: 1
  Paused: 0
  Stopped: 1
 Images: 21
 Server Version: 20.10.23
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: journald
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: /usr/libexec/docker/docker-init
 containerd version:
 runc version:
 init version:
 Security Options:
  seccomp
   Profile: default
  selinux
  cgroupns
 Kernel Version: 6.4.7-200.fc38.x86_64
 Operating System: Fedora CoreOS 38.20230806.3.0
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.741GiB
 Name: host.my.domain
 ID: CR4Q:RXX5:DAGC:X3RS:ZAP2:55RP:BTQO:AOF7:ZRPM:4B7G:V43B:NXRC
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: true

Additional Info

Tested on Fedora CoreOS 38 with dnsmasq running on the host (systemd-resolved also tried, the issue is the same).

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions