Podman network fails dns randomly

[Rashnan]

Issue Description

Podman's network fails DNS after some time. Ping works on host with domain name and ip, ping fails inside container with domain name, but succeeds with ip.
Have had this issue a few times atleast, all recent. The temporary solution I think is to kill the existing aarvark-dns process then bring down the container and recreate.
Maybe related I recently upgraded to podman 6.0.0.

Steps to reproduce the issue

Im not sure if this is the most accurate description, but it should not be an error with the docker compose below since I had this issue across another compose stack on the same machine which was using a php image.

1. I just bring up a compose app (example below)
2. Try to do dns queries. (Original error was package installs were failing)

services:
  app:
    depends_on:
      - db
    image: oven/bun:1.3-alpine
    volumes:
      - .:/home/bun/app
    env_file:
      - .env
    command: tail -f /dev/null
    # command: sh -c " \
    #   bun install --frozen-lockfile && \
    #   bun run dev"
    # command: bun run seed

3. The tests I tried

(inside container)
/home/bun/app # ping google.com
ping: bad address 'google.com'
/home/bun/app # exit
Error: executing /usr/lib/docker/cli-plugins/docker-compose exec -it app sh: exit status 1

~/Projects/ams-v3 master* 54s
❯ ping google.com
PING google.com (74.125.24.138) 56(84) bytes of data.
64 bytes from sf-in-f138.1e100.net (74.125.24.138): icmp_seq=1 ttl=108 time=58.9 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 58.933/58.933/58.933/0.000 ms

~/Projects/ams-v3 master*
❯ podman compose exec -it app ping 74.125.24.138
>>>> Executing external compose provider "/usr/lib/docker/cli-plugins/docker-compose". Please see podman-compose(1) for how to disable this message. <<<<

PING 74.125.24.138 (74.125.24.138): 56 data bytes
64 bytes from 74.125.24.138: seq=0 ttl=42 time=77.495 ms
^C
--- 74.125.24.138 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 77.495/77.495/77.495 ms

~/Projects/ams-v3 master*
❯ podman compose exec -it app ping google.com
>>>> Executing external compose provider "/usr/lib/docker/cli-plugins/docker-compose". Please see podman-compose(1) for how to disable this message. <<<<

ping: bad address 'google.com'
Error: executing /usr/lib/docker/cli-plugins/docker-compose exec -it app ping google.com: exit status 1

~/Projects/ams-v3 master*
❯

Describe the results you received

Package installs failed / pings with domain names failed, but those with IPs succeed.

Describe the results you expected

It should work. (even with domain name)

podman info output

❯ podman info
host:
  arch: amd64
  buildahVersion: 1.44.0
  cdiSpecDirs:
  - /etc/cdi
  - /var/run/cdi
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-1:2.2.1-1.1
    path: /usr/bin/conmon
    version: 'conmon version 2.2.1, commit: c8cc2c4db27531bd4e084ce7857f73cd21ee639d'
  cpuUtilization:
    idlePercent: 93.96
    systemPercent: 2.48
    userPercent: 3.56
  cpus: 16
  databaseBackend: sqlite
  distribution:
    distribution: cachyos
    version: unknown
  eventLogger: journald
  freeLocks: 2010
  hostname: zephc
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 7.1.2-3-cachyos
  linkmode: dynamic
  logDriver: journald
  memFree: 2097934336
  memTotal: 16126320640
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    defaultNetwork: podman
    dns:
      package: aardvark-dns-2.0.0-1.1
      path: /usr/lib/podman/aardvark-dns
      version: aardvark-dns 2.0.0
    package: netavark-2.0.0-1.1
    path: /usr/lib/podman/netavark
    version: netavark 2.0.0
  ociRuntime:
    name: crun
    package: crun-1.28-1.1
    path: /usr/bin/crun
    version: |-
      crun version 1.28-dirty
      commit: 54f16ffbefcd022bf032af768b5c5ce075c18bfc
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +JSON_C
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-2026_06_11.a9c61ff-1.1
    version: |
      pasta 2026_06_11.a9c61ff
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  rootlessPortForwarder: rootlessport
  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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  swapFree: 15821770752
  swapTotal: 16126046208
  uptime: 22h 15m 41.00s (Approximately 0.92 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries: {}
store:
  containerStore:
    number: 4
    paused: 0
    running: 4
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /home/rashnan/.local/share/containers/storage
  graphRootAllocated: 995907784704
  graphRootUsed: 75861327872
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 36
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/rashnan/.local/share/containers/storage/volumes
version:
  APIVersion: 6.0.0
  Built: 1783100882
  BuiltTime: Fri Jul  3 22:48:02 2026
  GitCommit: a8ed4b6dd12992decf659cadfdfb3d0cb1937748
  GoVersion: go1.26.4-X:nodwarf5
  Os: linux
  OsArch: linux/amd64
  Version: 6.0.0

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

CachyOS

Additional information

Has happened even after a couple restarts. The first few podman compose up's will be ok, but after a while it will show this error.

[Rashnan]

From my testing i found the internal dns would respond for other containers inside the compose (havent tried pinging other containers on same machine), but it would fail for public links like google.com.
Manually adding extra dns works as a band aid for now.

services:
  app:
    # depends_on:
    #   - db
    image: oven/bun:1.3-alpine
    volumes:
      - .:/home/bun/app
    env_file:
      - .env
    working_dir: /home/bun/app
    # command: tail -f /dev/null
    command: sh -c " \
      bun install --frozen-lockfile && \
      bun run dev"
    # command: bun run seed
    dns:
      - 1.1.1.1
      - 8.8.8.8

Would this be an issue in podman or docker compose or?

[Luap99]

I assume you run rootless? When this happens what is the output of podman unshare --rootless-netns sh -c "ip addr; ip route; cat /etc/resolv.conf"?

If local dns still works and manually adding the global dns it sounds liek the custom rootless-netns ends up with a unusable nameserver. For rootless we rely on the pasta --dns-forward proxy ip we set and that istels reads the /etc/resolv.conf on the host on startup to get the namesever.

Do you have the containers starting on boot via systemd? I guess it is likely that they start to early before the network configuration is done. Stopping aardvark-dns manually should not be required, to recreate the rootless-netns you need to stop all containers first and then start them again this should create a new namespace with a anew pasta and aardvark-dns process that pick up the current network config.

[Rashnan]

This is rootless podman with systemd.
I have tried to recreate this issue over the past few days, but after my report I havent been able to... I will try a few more times but either way should I close this issue?

[Viable8237]

Maybe related I recently upgraded to podman 6.0.0.

I think I recently experienced the same issue on v5.8. All of a sudden (after being up for weeks) DNS stopped working inside containers but worked on the host machine.

This is rootless podman with systemd.

I also run rootless with systemd.

I will try a few more times but either way should I close this issue?

I think the issue should not be closed until it's resolved since it seems it's not just an issue on your end.

[Viable8237]

Do you have the containers starting on boot via systemd? I guess it is likely that they start to early before the network configuration is done.

1. In my case the DNS issue appeared suddenly after the host machine and the containers had been up for weeks. If the issue was caused by an incorrect configuration startup order, wouldn't it be present immediately after bootup?
2. I thought configuring the container startup on boot via systemd is the standard way to do so. What are systemd users supposed to do if it doesn't work as it should?