Skip to content
This repository has been archived by the owner on Nov 27, 2023. It is now read-only.

unexpected behavior when a container is attached to more than one network #12

Open
abalage opened this issue Feb 4, 2020 · 4 comments

Comments

@abalage
Copy link

abalage commented Feb 4, 2020

Hi,

I experienced the following situation.
There are at least two CNI networks specified (CNI 1, CNI 2). Each has dnsname enabled. These networks are not overlapping.

If you join a container to both of these networks then:

  1. The container will have interfaces and IPs from both networks as expected.
  2. The container's resolv.conf will contain both network's name server like this.
nameserver 1.2.3.4
nameserver 5.6.7.8

Where 1.2.3.4 is authoritative to the domain of CNI 1, while 5.6.7.8 is authoritative to domain of CNI 2.

The problem with this approach is that host names on network 5.6.7.8 will never be resolved by the container as the first DNS server will always respond with NXDOMAIN as it is only authoritative to its own domain and does not forward request to 5.6.7.8 (it does not even suppose to).
The resolver will only fall back to 5.6.7.8 when 1.2.3.4 does not respond as all.

See an explanation example here: https://unix.stackexchange.com/questions/150703/can-subsequent-nameservers-defined-in-etc-resolv-conf-be-used-if-the-previous-n

I am not sure whether this effect is intended, though I thought it may be a good idea to report it.

@AlbanBedel
Copy link

Seeing this after opening #21 I'm wondering if it would not be a better design to have one config file per cni network and one dnsmasq process per container. Such a container specific dnsmasq would just include the config files of the networks it is bound to, solving this problem. Additionally the life cycle of the dnsmasq process and container would match, which would also solve #21.

@Arryboom
Copy link

Arryboom commented Dec 20, 2021

confirmed again 20/12/2021.

docker network create sqlnet
docker network create nginxnet
docker run --name web --network sqlnet webimage
docker run --name sql --network sqlnet sqlimage
docker network connect nginxnet web
docker run --name nginx --network nginxnet nginx

in sqlnet:

container web got ipaddress 10.89.0.2
container sql got ipaddress 10.89.0.3

in nginxnet:

container web got ipaddress 10.89.1.2

  1. after connect container web into nginxnet,and do docker restart web,web container won't able to resolve "sql" to ip,got

unknow name or service Error

  1. tried to modify domainName,doesnt work
>docker network inspect sqlnet
{
                "capabilities": {
                    "aliases": true
                },
                "domainName": "sql.net",
                "type": "dnsname"
            }
docker network inspect nginx.net
{
                "capabilities": {
                    "aliases": true
                },
                "domainName": "nginx.net",
                "type": "dnsname"
            }


@panumjp
Copy link

panumjp commented Jan 22, 2022

Hi,
It is possible to forward queries to other network's dnsmasq using server= option in dnsmasq.conf

At least my POC seems to work: panumjp@885f47e

@mheon
Copy link
Member

mheon commented Jan 24, 2022

That won't work, as it will allow all containers to see all other containers via DNS - even those in networks they are not present in.

We have abandoned dnsname due to this issue and are working on a new, custom server implementation that will resolve this, to be release with Podman 4.0.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants