Docker Community Forums

Share and learn in the Docker community.

Container IP (docker0 and docker_gwbridge interface IP's) is syncing with Host DNS why?

Hello All,

Recently I seen in one of my server, bridge0 and docker_gwbridge interface Ip’s are syncing with Host DNS server, and
causing authentication issues in the host? does anyone faced these issues, please let me know how did you fixed it?

Thank you
DP

What do you mean by "syncing with Host DNS server? What happens? Are you on MacOS? I ask it because I saw “bridge0” on MacOS only but I have never seen “bridge-gw”.

Overlay networks use this interface for communication amongst swarm cluster nodes.

Docker’s default behavior is to mount /etc/resolv.conf from the host into the container. Though, you can use cli arguments / compose file settings to override the behavior.

I am not sure how dns settings correlate with authentification issues. Can you provide examples?

So bridge-gw is like docker_gwbridge on Linux but on the Mac outside the VM?

Uh, I missred. In my head I did read it as docker_gwbridge and ment it in my response
You are right, there is no “bridge-gw” I am aware of either.

Sorry, my mistake it’s docker_gwbridge only, I have configured docker and swarm on RHEL 7. i found these issues in 2 to 3 servers, you can see below interface information, 172.18.0.1 and 172.17.0.1 Ip’s are resolving with host’s hostname. didn’t find this in other servers.

3: docker_gwbridge: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:19:06:b3:9a brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global docker_gwbridge
valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:36:c4:eb:16 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:36ff:fec4:eb16/64 scope link
valid_lft forever preferred_lft forever

it’s docker_gwbridge

No problem. I fixed it in the title, but I still don’t understand the resolving part of the issue. Can you help us with an example as @meyay asked?

Before docker configuration when i do nslookup, i use to get below update

[root@server5674 ~]# nslookup server5674
Server:         172.16.32.200
Address:        172.16.32.200#53

Name:   server5674.xxx.xxx
Address: 172.16.40.2

after docker configuration I am getting below, and logging in to host is taking too much time

[root@server5674 ~]# nslookup server5674
Server:         172.16.32.200
Address:        172.16.32.200#53

Name:   server5674.xxx.xxx
Address: 172.16.40.2
Name:   server5674.xxx.xxx
Address: 172.18.0.1
Name:   server5674.xxx.xxx
Address: 172.20.0.1

Its a surprise to me that nslookup on the same host returns those entries. The last two entries of the second block look like gateway ip’s of docker bridges.

can you share the output of /etc/resolv.conf and if you see nameservers that are not expected, which one those are?

So the problem is that docker registers those ip’s on some host and doesn’t on others? Or is the problem that docker registers the ip’s on dns at all?

Yes Metin, below 2 IP’s from Docker
Name: server5674.xxx.xxx
Address: 172.18.0.1
Name: server5674.xxx.xxx
Address: 172.20.0.1

nothing suspecious or unexpected in /etc/resolv.conf file.

cat /etc/resolv.conf

domain xxx.xxx
search xxx.xxx
nameserver 172.16.32.200
nameserver 172.16.32.201
nameserver 172.17.32.200

looks like docker registering these ip’s in dns, don’t know how?
why because from other servers nslookup is showing hosts hostname is resolving with docker ip’s.

i am seeing this first time, normally docker ip’s won’t resolve host’s hostname from outside.

I know, most of them didn’t see these issues, so requested Infra guys to check on VM’s and their Net configs

I can’t see the same behavior on my cluster machines.

By any chance, do the docker network subnets and your local subnet ranges intersect?

Also I am curious which docker package you use, some docker distributions like the snap docker package for instance are modified in behavior in order to allign with the package distributor’s philosopy. Can you share the ouput of docker version?