[Bug]: DNS doesn't work for containers

[m0nhawk]

Issue Description

Connecting from one container to another via names.

Steps to reproduce the issue

Steps to reproduce the issue

1. Create network:

podman network create default

2. Create one container:

podman run -it --rm --network default -p 80:80 --name nginx nginx

3. Create another container:

podman run -it --rm --network default fedora:37 bash

4. Try to connect from second container:

curl nginx

Describe the results you received

curl: (6) Could not resolve host: nginx

Describe the results you expected

Resolve of DNS name and default nginx page.

podman info output

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.5-1.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: '
  cpuUtilization:
    idlePercent: 97.68
    systemPercent: 1.12
    userPercent: 1.2
  cpus: 1
  distribution:
    distribution: fedora
    variant: coreos
    version: "37"
  eventLogger: journald
  hostname: vultr.guest
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.0.15-300.fc37.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 283000832
  memTotal: 1010069504
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.7.2-2.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.7.2
      commit: 0356bf4aff9a133d655dc13b1d9ac9424706cac4
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 0h 30m 59.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 26295119872
  graphRootUsed: 4537229312
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 4
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 1668178887
  BuiltTime: Fri Nov 11 15:01:27 2022
  GitCommit: ""
  GoVersion: go1.19.2
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

No

Additional environment details

No additional details, tried clean installs of Fedora 37 and Fedora CoreOS 37, both rootless and rootfull containers, both DOESN'T work.

Additional information

[root@vultr core]# podman run -it --rm --network default fedora:37 cat /etc/resolv.conf
nameserver 108.61.10.10

Adding --hostname doesn't help.

[flouthoc]

I think dns is usually not enabled on default network, could you please do podman network inspect default and paste the output, if it contains "dns_enabled": false, I think its better to create a new network which have by default dns_enabled.

[vrothberg]

Yes, that's correct. DNS is disabled for the default network. New networks have DNS enabled by default.

Does it work with another (newly created) network, @m0nhawk ?

[Luap99]

podman network create default should not be a valid command. The default word is already reserved for a different use as network mode. We already block certain names, default must be added as well.

[m0nhawk]

The newly created network (with default as a name) have dns_enabled set to true, so that was not the issue.

@Luap99 I appreciate for this comment, I just tried this with different network name and it's working as expected. Though, I couldn't find any limits on network names while skimming documentation, and the default podman network is called podman, so I haven't though the podman network create default shouldn't actually work.

[Luap99]

Well in terms if network names the backend code does not care, the problem is with the cli parsing podman run --network default ... will make the cli think you want to use the default network mode, which is slirp4nents as rootless and bridge as root. There is no good way of knowing what the user intent was. So IMO the only reasonable fix is to block users from creating a network with the name default which is what my linked PR does.

[rhatdan]

Remind me why DNS is not working on the default network. I know Docker does it this way, but it seems like a stupid default, and people are always opening issues on it, or figuring it does not work at all.