The possible DNS problem for running 'sudo apt-get update' in deepin desktop docker container started by x11docker.

[hongyi-zhao]

Hi,

First I start the deepin desktop docker container with x11docker as follows:

$ x11docker --desktop --sudouser --clipboard --init=systemd -- --cap-add=IPC_LOCK --security-opt seccomp=unconfined -- x11docker/deepin

But I failed to run the following command in the docker container:

werner@f1d836161f10:~/Desktop$ sudo apt-get update

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for werner: 
Err:1 http://mirrors.kernel.org/deepin lion InRelease
  Temporary failure resolving 'mirrors.kernel.org'
Reading package lists... Done
W: Failed to fetch http://mirrors.kernel.org/deepin/dists/lion/InRelease  Temporary failure resolving 'mirrors.kernel.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.

It seems like a DNS problem. Any hints for solving this problem?

Regards, HY

[mviereck]

It might help to change the source repository as described yet in #5 . Build a new image with:

FROM x11docker/deepin
RUN echo "deb http://packages.deepin.com/deepin/ lion main non-free contrib" > /etc/apt/sources.list
RUN apt-get update

This mirror is located in China and should work better inside of China. EDIT: A long list of deepin repository mirrors: https://www.deepin.org/en/mirrors/packages/

You can test this before in a running x11docker/deepin container with:

sudo echo "deb http://packages.deepin.com/deepin/ lion main non-free contrib" > /etc/apt/sources.list
sudo apt-get update

[hongyi-zhao]

sudo echo "deb http://packages.deepin.com/deepin/ lion main non-free contrib" > /etc/apt/sources.list

The following command should be used for the above purpose:

$ echo "deb http://packages.deepin.com/deepin/ lion main non-free contrib" | sudo tee /etc/apt/sources.list

sudo apt-get update

Still failed. See following for more info:

werner@7e374e5eeef6:~/Desktop$ cat /etc/apt/sources.list
deb http://packages.deepin.com/deepin/ lion main non-free contrib
werner@7e374e5eeef6:~/Desktop$ sudo apt-get update
Err:1 http://packages.deepin.com/deepin lion InRelease
  Temporary failure resolving 'packages.deepin.com'
Reading package lists... Done
W: Failed to fetch http://packages.deepin.com/deepin/dists/lion/InRelease  Temporary failure resolving 'packages.deepin.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

[mviereck]

I am not sure what the underlying issue is. I assume it is somehow an issue with your network setup.

Does ping packages.deepin.com work on your host? Does this one work? (ping in a debian container)

docker run --rm debian ping packages.deepin.com

[hongyi-zhao]

I am not sure what the underlying issue is. I assume it is somehow an issue with your network setup.

Does ping packages.deepin.com work on your host?

$ ping -c4 packages.deepin.com 
PING packages.deepin.com (58.51.151.5) 56(84) bytes of data.
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=1 ttl=56 time=24.5 ms
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=2 ttl=56 time=25.1 ms
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=3 ttl=56 time=24.7 ms
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=4 ttl=56 time=24.4 ms

--- packages.deepin.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 24.361/24.648/25.098/0.283 ms

Does this one work? (ping in a debian container)

docker run --rm debian ping packages.deepin.com

$ docker run --rm debian ping packages.deepin.com
Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
e4c3d3e4f7b0: Pull complete 
Digest: sha256:8414aa82208bc4c2761dc149df67e25c6b8a9380e5d8c4e7b5c84ca2d04bb244
Status: Downloaded newer image for debian:latest
ping: packages.deepin.com: Temporary failure in name resolution

$ docker run --rm debian ping -c4 58.51.151.5 PING 58.51.151.5 (58.51.151.5) 56(84) bytes of data. From 172.17.0.2 icmp_seq=1 Destination Host Unreachable From 172.17.0.2 icmp_seq=2 Destination Host Unreachable From 172.17.0.2 icmp_seq=3 Destination Host Unreachable From 172.17.0.2 icmp_seq=4 Destination Host Unreachable

--- 58.51.151.5 ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 62ms pipe 4

[mviereck]

So the issue is network connection in docker containers in general.

As a temporary workaround you can use x11docker option --hostnet. For building an image use docker build --network=host [...]. Both workarounds disable network namespacing, so I discourage it and recommend to fix the underlying issue.

I found this thread that might help: https://stackoverflow.com/questions/20430371/my-docker-container-has-no-internet

As a first check, compare the outputs of

cat /etc/resolv.conf
docker run --rm debian cat /etc/resolv.conf

Edit:

The 127.0.0.1:8080 is local working http proxy for docker set by me.

Maybe it helps to publish port 8080 to the container. Something like this might work:

x11docker --sudouser -- --publish 8080:8080 -- x11docker/deepin deepin-terminal

[hongyi-zhao]

So the issue is network connection in docker containers in general.

As a temporary workaround you can use x11docker option --hostnet.

This fix the problem. See my following steps for more info:

1. Start the docker container as follows:

$ x11docker --hostnet --desktop --sudouser --clipboard --init=systemd -- --cap-add=IPC_LOCK --security-opt seccomp=unconfined -- x11docker/deepin

2. Check the problem in the docker container:

werner@X10DAi-01:~/Desktop$ echo "deb http://packages.deepin.com/deepin/ lion main non-free contrib" | sudo tee /etc/apt/sources.list

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for werner: 
deb http://packages.deepin.com/deepin/ lion main non-free contrib
werner@X10DAi-01:~/Desktop$ sudo apt-get update
Get:1 http://packages.deepin.com/deepin lion InRelease [11.4 kB]
Get:2 http://packages.deepin.com/deepin lion/main amd64 Packages [15.5 MB]
Get:3 http://packages.deepin.com/deepin lion/non-free amd64 Packages [240 kB]
Get:4 http://packages.deepin.com/deepin lion/contrib amd64 Packages [114 kB]
Fetched 15.9 MB in 1s (8,825 kB/s)                        
Reading package lists... Done

For building an image use docker build --network=host [...].

I haven't tried this solution due to its time-consuming characteristics.

Both workarounds disable network namespacing, so I discourage it and recommend to fix the underlying issue.

Agree with you.

I found this thread that might help: https://stackoverflow.com/questions/20430371/my-docker-container-has-no-internet

As a first check, compare the outputs of

cat /etc/resolv.conf

$ cat /etc/resolv.conf | egrep -v '^(#|$)'
nameserver 127.0.0.53
options edns0

docker run --rm debian cat /etc/resolv.conf

werner@X10DAi-01:~$ docker run --rm debian cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0

Edit:

> The 127.0.0.1:8080 is local working http proxy for docker set by me.

Maybe it helps to publish port 8080 to the container. Something like this might work:

x11docker --sudouser -- --publish 8080:8080 -- x11docker/deepin deepin-terminal

Failed to start the docker container with this method. See the log of std(out/err) for more info:

werner@X10DAi-01:~$ x11docker --sudouser -- --publish 8080:8080 -- x11docker/deepin deepin-terminal
x11docker WARNING: User werner is member of group docker.
  That allows unprivileged processes on host to gain root privileges.

x11docker note: Using X server option --xpra

x11docker note: Option --xpra: If you encounter issues with xpra, 
  you can try --nxagent instead.
  Rather use xpra from www.xpra.org than from distribution repositories.

x11docker WARNING: Found custom DOCKER_RUN_OPTIONS.
  x11docker will add them to 'docker run' command without
  a serious check for validity or security. Found options:
   '--publish' '8080:8080'

x11docker WARNING: Option --sudouser severly reduces container security.
  Container gains additional capabilities to allow sudo and su.
  If an application breaks out of container, it can harm your system
  in many ways without you noticing. Password: x11docker

x11docker note: Option --sudouser: Enabling option --newprivileges=yes.
  You can avoid this with --newprivileges=no

x11docker WARNING: Option --newprivileges=yes: x11docker does not set 
  docker run option --security-opt=no-new-privileges. 
  That degrades container security.
  However, this is still within a default docker setup.

docker: Error response from daemon: driver failed programming external connectivity on endpoint x11docker_X106_x11docker-deepin-deepin-terminal_74484798640 (c54f5fecc21dff873f29b066827a788f7bf683f0f90a850c2b8b50b629797097): Error starting userland proxy: listen tcp 0.0.0.0:8080: bind: address already in use.

x11docker ERROR: dockerrc(): Did not receive PID of PID1 in container. 
  Maybe the container immediately stopped for unknown reasons. 
  Just in case, check if host and image architecture are compatible: 
  Host architecture: amd64 (x86_64), image architecture: amd64. 
  Output of "docker ps | grep x11docker": 

  Content of container log: 
WARNING: No swap limit support 
Error: No such container: x11docker_X106_x11docker-deepin-deepin-terminal_74484798640 
Error: No such object: x11docker_X106_x11docker-deepin-deepin-terminal_74484798640

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /home/werner/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

werner@X10DAi-01:~$ 

[hongyi-zhao]

I find another very strange DNS problem relevant to the issue reported here. See following for detailed description.

1. Set the following default DNS for docker globally:

$ grep -A2 'dns' /etc/docker/daemon.json
  "dns": [
    "8.8.8.8"
  ],

werner@X10DAi-01:~$ sudo systemctl restart docker
werner@X10DAi-01:~$ ip a s docker0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:48:99:2e:bb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:48ff:fe99:2ebb/64 scope link 
       valid_lft forever preferred_lft forever

2. Check the DNS settings used by docker container:

werner@X10DAi-01:~$ docker run --rm debian cat /etc/resolv.conf
nameserver 8.8.8.8
werner@X10DAi-01:~$ ip a s docker0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:48:99:2e:bb brd ff:ff:ff:ff:ff:ff
    inet6 fe80::42:48ff:fe99:2ebb/64 scope link 
       valid_lft forever preferred_lft forever
werner@X10DAi-01:~$ sudo systemctl restart docker
werner@X10DAi-01:~$ ip a s docker0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:48:99:2e:bb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:48ff:fe99:2ebb/64 scope link 
       valid_lft forever preferred_lft forever
werner@X10DAi-01:~$ docker run --rm debian ping -c4 packages.deepin.com
PING packages.deepin.com (58.51.151.5) 56(84) bytes of data.
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=1 ttl=55 time=24.6 ms
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=2 ttl=55 time=24.5 ms
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=3 ttl=55 time=24.4 ms
64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=4 ttl=55 time=24.4 ms

--- packages.deepin.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 24.367/24.481/24.629/0.148 ms
werner@X10DAi-01:~$ ip a s docker0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:48:99:2e:bb brd ff:ff:ff:ff:ff:ff
    inet6 fe80::42:48ff:fe99:2ebb/64 scope link 
       valid_lft forever preferred_lft forever
werner@X10DAi-01:~$ docker run --rm debian ping -c4 packages.deepin.com
ping: packages.deepin.com: Temporary failure in name resolution
werner@X10DAi-01:~$ 

As you can see, The docker run command will clean up the IP address on docker0 NIC, which will cause the network connection problem for all docker containers. As a temporary solution/workaround, I must run sudo systemctl restart docker command immediately after each docker run command.

Any hints for this problem?

Regards, HY

[mviereck]

As you can see, The docker run command will clean up the IP address on docker0 NIC, which will cause the network connection problem for all docker containers. As a temporary solution/workaround, I must run sudo systemctl restart docker command immediately after each docker run command.

That looks very odd. I have no idea what is going on and why the ipv4 adress gets lost after docker run.

werner@X10DAi-01:~$ docker run --rm debian cat /etc/resolv.conf nameserver 127.0.0.53 options edns0

In the container 127.x.x.x is a local container network different from the local host network. So this cannot work unless setting --network=host.

I found a documentation how to configure docker to use a local proxy from host: https://docs.docker.com/network/proxy/ According to the documentation you'll need a file ~/.docker/config.json with a configuration like this:

{
 "proxies":
 {
   "default":
   {
     "httpProxy": "http://127.0.0.1:8080",
     "httpsProxy": "http://127.0.0.1:8080",
     "noProxy": "*.test.example.com,.example2.com"
   }
 }
}

I am not sure if this configuration could be done globally in /etc/docker/daemon.json as well.

[hongyi-zhao]

I've already created the configuration file ~/.docker/config.json some time before. See the following for its content used by me:

$ cat ~/.docker/config.json
{
 "proxies":
 {
   "default":
   {
     "httpProxy": "http://127.0.0.1:8080",
     "httpsProxy": "http://127.0.0.1:8080",
     "noProxy": "localhost,127.0.0.1",
     "comment": "https://docs.docker.com/network/proxy/#configure-the-docker-client"
   }
 }
}

The problem is: even I use the same settings in the /etc/docker/daemon.json, the loopback address 127.0.0.1 is of the host and I'm afraid that it doesn't mean the same thing when using it in the docker container.

[mviereck]

The problem is: even I use the same settings in the /etc/docker/daemon.json, the loopback address 127.0.0.1 is of the host and I'm afraid that it doesn't mean the same thing when using it in the docker container.

From my understanding docker should redirect the container network to the proxy on host with this configuration. Not sure why it does not work nonetheless.

I admit I am stuck here. I am not experienced with network setups in general or docker networks in special. Because this is a docker specific issue, I recommend to ask elsewhere how to solve this. Sorry, I am just running out of ideas.

[mviereck]

Some ideas:

• Remove the line "noProxy": "localhost,127.0.0.1",
• Remove the DNS setting in /etc/docker/daemon.json
• Try 127.0.0.53 instead of 127.0.0.1

Edit: Maybe some iptables or ufw settings disallow access?

[hongyi-zhao]

Thanks for your endeavor, notes and ideas. I also think that the best solution for this problem is to ask on docker's mail list/forum.

And first, I myself should also try to study/learn intensively the network relative docs for docker. Do my due diligence so that I can later communicate with others better.

[hongyi-zhao]

I noticed another strange thing. Let me describe it in detail as follows.

As to the default bridge network for my case, I see the following configurations:

werner@X10DAi-01:~$ docker network inspect bridge 
[
    {
        "Name": "bridge",
        "Id": "0f8998f6eb07309e2d7094015c88f76d241fd361f57b3b278483a8dc1dabeabe",
        "Created": "2020-10-26T20:15:06.564014045+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

But the tutorial here gives the following typical result:

$ docker network inspect bridge

[
    {
        "Name": "bridge",
        "Id": "17e324f459648a9baaea32b248d3884da102dde19396c25b30ec800068ce6b10",
        "Created": "2017-06-22T20:27:43.826654485Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Containers": {
            "602dbf1edc81813304b6cf0a647e65333dc6fe6ee6ed572dc0f686a3307c6a2c": {
                "Name": "alpine2",
                "EndpointID": "03b6aafb7ca4d7e531e292901b43719c0e34cc7eef565b38a6bf84acf50f38cd",
                "MacAddress": "02:42:ac:11:00:03",
                "IPv4Address": "172.17.0.3/16",
                "IPv6Address": ""
            },
            "da33b7aa74b0bf3bda3ebd502d404320ca112a268aafe05b4851d1e3312ed168": {
                "Name": "alpine1",
                "EndpointID": "46c044a645d6afc42ddd7857d19e9dcfb89ad790afb5c239a35ac0af5e8a5bc5",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

The most significant difference is my result doesn't include the following setting:

"Gateway": "172.17.0.1"

Any hints for this problem?

Regards

[mviereck]

Not sure why your bridge configuration looks different.

In my case it looks similar to your tutorial example:

                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"

Maybe the difference is caused by your ~/.docker/config.json?

Full output of docker network inspect bridge:

[
    {
        "Name": "bridge",
        "Id": "a86cfba1eb256f4d85461bd1c8cfa05493dec7b7fdb3f87108b8efa3bc9ab724",
        "Created": "2020-10-28T08:36:09.898949325+01:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "6cd1f518888778c75a868d0281eb598e9e213b89c2ca98c64bc5efce9f2b0e77": {
                "Name": "x11docker_X101_x11docker-firefox_70580877950",
                "EndpointID": "9f10c927061ff39b4ab602c96eea85de7b299a00499a0ca0639f9458b96327f0",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

[hongyi-zhao]

Not sure why your bridge configuration looks different.

In my case it looks similar to your tutorial example:

                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"

An even stranger phenomenon is that the problem only appears when I just started the system and can be solved by running sudo systemctl restart docker. See following for detail:

werner@X10DAi-01:~$ docker network inspect bridge | grep -i gateway
werner@X10DAi-01:~$ sudo systemctl restart docker
werner@X10DAi-01:~$ docker network inspect bridge | grep -i gateway
                    "Gateway": "172.17.0.1"

[mviereck]

An even stranger phenomenon is that the problem only appears when I just started the system and can be solved by running sudo systemctl restart docker

Maybe systemd somehow starts the docker daemon before the network setup is ready?

[hongyi-zhao]

I finally find out a not too bad method. The detailed steps and further questions are described as follows. Any comments/enhancements/fixes are welcome.

1. Set the IP address of docker0, i.e., 172.17.0.1, as the DNS server for docker container:

$ ip a show docker0 4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:71:92:67:c2 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever inet6 fe80::42:71ff:fe92:67c2/64 scope link valid_lft forever preferred_lft forever

$ cat /etc/docker/daemon.json { "dns": [ "172.17.0.1" ] }

2. Ensure the gateway for bridge network is set with the ip address of docker0:

$ docker network inspect bridge | grep -i gateway "Gateway": "172.17.0.1"

3. Running a dnsforwarder on docker0 using dnsmasq with the host
network DNS server as the upstream. Be sure to exclude the lo interface, otherwise the loop DNS query problem will happen.

$ sudo dnsmasq -a 172.17.0.1 -S 127.0.0.53 --bind-dynamic -d -h -R -q or $ sudo dnsmasq -i docker0 -I lo -S 127.0.0.53 --bind-dynamic -d -h -R -q

4. Test the DNS resolution in docker container and checking the log of
dnsmasq for further confirmation:

$ docker run --rm debian ping -c4 packages.deepin.com PING packages.deepin.com (58.51.151.5) 56(84) bytes of data. 64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=1 ttl=55 time=23.9 ms 64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=2 ttl=55 time=24.4 ms 64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=3 ttl=55 time=24.4 ms 64 bytes from 58.51.151.5 (58.51.151.5): icmp_seq=4 ttl=55 time=24.3 ms

--- packages.deepin.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 7ms rtt min/avg/max/mdev = 23.942/24.272/24.429/0.193 ms

werner@X10DAi-01:~$ sudo dnsmasq -a 172.17.0.1 -S 127.0.0.53 --bind-dynamic -d -h -R -q dnsmasq: started, version 2.82 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN DHCP DHCPv6 Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile dnsmasq: using nameserver 127.0.0.53#53 dnsmasq: cleared cache dnsmasq: query[A] packages.deepin.com from 172.17.0.3 dnsmasq: forwarded packages.deepin.com to 127.0.0.53 dnsmasq: query[AAAA] packages.deepin.com from 172.17.0.3 dnsmasq: forwarded packages.deepin.com to 127.0.0.53 dnsmasq: reply packages.deepin.com is 58.51.151.5 dnsmasq: query[PTR] 5.151.51.58.in-addr.arpa from 172.17.0.3 dnsmasq: forwarded 5.151.51.58.in-addr.arpa to 127.0.0.53

As you can see, the above steps will do the trick for me. But I want
to re-implement the step 3 with iptables to further simplify the tool
chain. In one word, I want to create a dnsforwarder using iptables for
docker container to use the host network's DNS server.

For this purpose, I tried the following settings based on the
instructions from
<https://unix.stackexchange.com/questions/144482/iptables-to-redirect-dns-lookup-ip-and-port>,
but failed, see the following for the detailed iptables rules testing
by me on my Ubuntu 20.04 box:

sudo iptables -t nat -A OUTPUT -o docker0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.53:53 sudo iptables -t nat -A OUTPUT -o docker0 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.53:53 sudo iptables -t nat -A POSTROUTING -o docker0 -j MASQUERADE

or

sudo iptables -t nat -A PREROUTING -i docker0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.53:53 sudo iptables -t nat -A PREROUTING -i docker0 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.53:53 sudo iptables -t nat -A POSTROUTING -o docker0 -j MASQUERADE

NB. The original iptables rules is shown below for your info:

werner@X10DAi-01:~$ sudo iptables-save

Generated by iptables-save v1.8.4 on Sun Nov 1 23:37:53 2020

*filter :INPUT ACCEPT [2395226:307433695] :FORWARD DROP [0:0] :OUTPUT ACCEPT [2498618:357744169] :DOCKER - [0:0] :DOCKER-ISOLATION-STAGE-1 - [0:0] :DOCKER-ISOLATION-STAGE-2 - [0:0] :DOCKER-USER - [0:0] -A FORWARD -j DOCKER-USER -A FORWARD -j DOCKER-ISOLATION-STAGE-1 -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -o docker0 -j DOCKER -A FORWARD -i docker0 ! -o docker0 -j ACCEPT -A FORWARD -i docker0 -o docker0 -j ACCEPT -A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2 -A DOCKER-ISOLATION-STAGE-1 -j RETURN -A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP -A DOCKER-ISOLATION-STAGE-2 -j RETURN -A DOCKER-USER -j RETURN COMMIT

Completed on Sun Nov 1 23:37:53 2020

Generated by iptables-save v1.8.4 on Sun Nov 1 23:37:53 2020

*nat :PREROUTING ACCEPT [15:4527] :INPUT ACCEPT [14:4443] :OUTPUT ACCEPT [71742:4329105] :POSTROUTING ACCEPT [71742:4329105] :DOCKER - [0:0] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE -A DOCKER -i docker0 -j RETURN COMMIT

Completed on Sun Nov 1 23:37:53 2020

Any hints for this problem is highly appreciated.

Sincerely,
HY

[mviereck]

Thank you for sharing your findings! Great that you found a working setup with dnsmasq.

I have no experience with iptables at all, but I'll have a look if I have an idea. Do you look for iptables instead of dnsmasq to need less running services?

[hongyi-zhao]

Do you look for iptables instead of dnsmasq to need less running services?

This is one of the reasons. In addition to this, the iptables solution should have higher efficiency and performance because it interacts directly with the kernel to complete the work.

Last but not least, mastering/learning iptables is not an easy task, but I believe that questions are the gateway to answers. Hence, I want to give it a try.

[hongyi-zhao]

Got it. The following iptables rules will do the trick:

$ sudo iptables -t nat -I PREROUTING -i docker0 -p udp --dport 53 -j DNAT --to-destination 127.0.0.53
$ sudo iptables -t nat -I PREROUTING -i docker0 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.53

[mviereck]

Got it. The following iptables rules will do the trick:

Great! Thank you for sharing your solution.

One late idea why the setup with Docker configuration in daemon.json might fail: Maybe your lokal proxy only accepts connections from localhost and rejects connections from the Docker network. You might need to explicitly allow 172.17.0.0/16 in the configuration of the proxy itself.

[hongyi-zhao]

One late idea why the setup with Docker configuration in daemon.json might fail: Maybe your lokal proxy only accepts connections from localhost and rejects connections from the Docker network. You might need to explicitly allow 172.17.0.0/16 in the configuration of the proxy itself.

I'm not sure which setting are you referring to? Could you please point it more specifically? BTW, see here for some relative discussions.

Regards, HY

[mviereck]

I mean this configuration that you tried above:

I've already created the configuration file ~/.docker/config.json some time before. See the following for its content used by me:

$ cat ~/.docker/config.json { "proxies": { "default": { "httpProxy": "http://127.0.0.1:8080", "httpsProxy": "http://127.0.0.1:8080", "noProxy": "localhost,127.0.0.1", "comment": "https://docs.docker.com/network/proxy/#configure-the-docker-client" } } }

Maybe the proxy can see that the requests come from a different network than localhost and denies the requests.

[hongyi-zhao]

The solution is set the HTTP proxy on docker0 interface and use the following config file:

werner@ubuntu-01:~$ cat .docker/config.json 
{
 "proxies":
 {
   "default":
   {
     "httpProxy": "http://172.17.0.1:8080",
     "httpsProxy": "http://172.17.0.1:8080",
     "noProxy": "localhost,127.0.0.1",
     "comment": "https://docs.docker.com/network/proxy/#configure-the-docker-client"
   }
 }
}