,

The container name resolution conundrum

One of the questions we in the Podman world often are asked is “Why can’t my container resolve other containers by name?” In many of the cases, the answer is … because you are running on a network with name resolution disabled. In fact, you are likely running on the *default* network; which indeed does not have name resolution enabled. The next question then is “why is Podman doing that?” And the standard answer? “Because Docker does that and people want Docker compatibility as much as possible.”

Let’s take a closer look by example. I’ll be using containers created by a privileged user because that is sort of the Docker standard. In each example, I will launch two named containers on the same network and show name resolution success and failure.

In this first example, we confirm only the default Podman network exists. It is called podman and it cannot be removed. Remembering that the default network does not have name resolution enabled, any attempts to do so should and do fail. Notice that test2 is unable to resolve test1 by name.

$ sudo podman network ls
NETWORK ID    NAME        DRIVER
2f259bab93aa  podman      bridge
$ sudo podman run --rm -dt --name test1 alpine top
3703d80740513421772db407972111ad6f535f5ca214f11ddb714a7d64ee140c
$ sudo podman run --rm -it --name test2 alpine /bin/sh
/ # ping test1
ping: bad address 'test1'
/ # exit

One solution is to then create a new network which I called new. By default, all created networks do have name resolution enabled and must opt-out in order to disable it. Then I run two containers in the same way as before except that I cite a different network and name resolution works as expected.

$ sudo podman network create new
new
$ sudo podman network ls
NETWORK ID    NAME        DRIVER
d9376e135b46  new         bridge
2f259bab93aa  podman      bridge
$ sudo podman run --rm -dt --name test1 --network new alpine top
f5a8d256f29221676dc7fca36bca0b680dd7de4a5aa20af2a9d9a02072b34fc7
$ sudo podman run --rm -it --name test2 --network new alpine /bin/sh
/ # ping test1
PING test1 (10.89.0.2): 56 data bytes
64 bytes from 10.89.0.2: seq=0 ttl=42 time=0.114 ms
64 bytes from 10.89.0.2: seq=1 ttl=42 time=0.107 ms
^C

I mentioned earlier that one of the reasons Podman behaves this way is because Docker does as well. Performing the same test with Docker’s default network, we can see name resolution does not work either. The solution is the same as Podman where you create a new network and run your containers there.

ubuntu@ubuntu:~$ sudo docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
cb0c4d38339a   bridge    bridge    local
5d0fce56bcad   host      host      local
18c31437e8d0   none      null      local
ubuntu@ubuntu:~$ sudo docker run -dt --name test1 alpine top
b23e15c969d253f33f99bd2cecb00b4b061e2a7605190eae683f546692ea34cc
ubuntu@ubuntu:~$ sudo docker run -it --name test2 alpine /bin/sh
/ # ping test1
ping: bad address 'test1'
/ # exit

If you always want your containers to have name resolution but you do not want to have to cite the different network for each container, you can make any network the default network for containers. It requires a small change to /etc/containers/containers.conf (or simple addition if containers.conf does not exist).

$ sudo cat /etc/containers/containers.conf
[network]
default_network = "new"
$ sudo podman run -dt --rm --name test1 alpine top
18d033aeec0640100bf8165c23b01e55c03fbd5bc320d874a3f4f01f755512c7
$ sudo podman run -it --rm --name test2 alpine /bin/sh
/ # ping test1
PING test1 (10.89.0.5): 56 data bytes
64 bytes from 10.89.0.5: seq=0 ttl=42 time=0.137 ms
64 bytes from 10.89.0.5: seq=1 ttl=42 time=0.106 ms
^C
--- test1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.106/0.121/0.137 ms
/ # exit

Note here that new is the default network and name resolution works.

We have also been asked why does Podman mimic Docker on this behavior especially when a lot of people do want name resolution by default. My personal answer is two-fold. I do not know why Docker did it but I do not want to find out, and Podman users like to call us out when we are not bug for bug compatible with Docker. The second reason I would not want name resolution enabled by default is because it takes just a little longer for the container to run. Podman always has to use netavark to set up networking but when name resolution is enabled, netavark also has to call out to aardvark-dns. The amount of time might be nearly nothing, but in some cases this matters.

Brent Baude

Senior Principal Software Engineer, Podman Architect

One response to “The container name resolution conundrum”

  1. runiq Avatar

    Is there a way to enable name resolution for the default network in containers.conf?

Leave a Reply to runiqCancel reply

Subscribe

Sign up with your email address to receive updates by email from this website.


Categories


Search