Docker Containers fails to DNS resolve on subnet 10.0.2.0/24

Question

The ultimate problem I am facing is this:

[root@527eb70c04c9 my-service]# ping google.com
ping: google.com: Name or service not known

Inside my container, I can't resolve public domains, although the network is defined as not internal:

networks:
  my-service-network:
    driver: overlay
    internal: false
    attachable: true
    ipam:
      driver: default
      config:
        - subnet: 10.0.2.0/24

As soon as I change my subnet from 10.0.2.0 to 10.0.5.0 (really just "NOT" have it be 10.0.2.0) everything works:

networks:
  ess-team-service:
    driver: overlay
    internal: false
    attachable: true
    labels:
      - "group=ess-services"
    ipam:
      driver: default
      config:
      - subnet: 10.0.5.0/24

ping google.com
PING google.com (172.217.22.14) 56(84) bytes of data.
64 bytes from fra16s14-in-f14.1e100.net (172.217.22.14): icmp_seq=1 ttl=61 time=25.0 ms
64 bytes from fra16s14-in-f14.1e100.net (172.217.22.14): icmp_seq=2 ttl=61 time=22.7 ms
64 bytes from fra16s14-in-f14.1e100.net (172.217.22.14): icmp_seq=3 ttl=61 time=22.5 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 22.575/23.462/25.083/1.161 ms

A colleague referred to the problem as being caused because Docker's own nameserver is on 10.0.2.0 but I can't find information to back this theory up let alone confirm it.

The main problem is: Sometimes it works. Most times it doesn't but sometimes I can ping google inside the container while the subnet IS 10.0.2.0

Answer 1

We have not been able to figure out what the problem is or what a solution could be.

The workaround is actually not using the 10.0.2.0 subnet, so I will add that as an answer as requested in the comments.

If someone finds the real issue and solution here, I will gladly accept that answer though.