使用多容器Rootless Podman时出现间歇性DNS解析失败是否为预期行为？

这绝对不是预期的设计行为——你遇到的问题其实是aardvark-dns在处理SIGHUP刷新操作时的一个已知局限性，尤其在容器频繁重启的场景下会被放大。

先给你理清楚背后的逻辑：当容器被移除时，Podman会给aardvark-dns发送SIGHUP信号，目的是让它更新DNS记录（删掉已移除容器的条目）。但早期版本的aardvark-dns处理这个刷新是阻塞式的——也就是说，刷新期间它会暂停响应新的DNS请求，这就导致了短暂的解析失败。你提到的4-5个容器每天就有多次失败，要是到10个左右，这个问题会更严重，完全符合你说的“二次增长”的趋势，这显然不符合正常使用的预期。

咱们来看你提供的日志，里面明确标记了关键触发点：

Feb 19 22:04:46 our_host systemd[590631]: libpod-96f36b743fc774866fb779d8c39e8b111122223333b2c23291a25de1bb2184b9.scope: Consumed 1min 32.870s CPU time.
Feb 19 22:04:46 our_host podman[2159020]: @ - - [19/Feb/2024:22:03:54 +0100] "POST /v1.41/containers/96f36b743fc774866fb779d8c39e8b111122223333b2c23291a25de1bb2184b9/attach?stderr=1&stdin=1&stdout=1&stream=1 HTTP/1.1" 200 0 "" "Docker-Client/unknown-version (linux)"
Feb 19 22:04:46 our_host aardvark-dns[3621325]: Received SIGHUP will refresh servers: 1
Feb 19 22:04:46 our_host kernel: podman1: port 1(veth5) entered disabled state
Feb 19 22:04:46 our_host kernel: device veth5 left promiscuous mode
Feb 19 22:04:46 our_host kernel: podman1: port 1(veth5) entered disabled state
Feb 19 22:04:46 our_host podman[2159020]: @ - - [19/Feb/2024:22:03:54 +0100] "POST /v1.41/containers/96f36b743fc774866fb779d8c39e8b111122223333b2c23291a25de1bb2184b9/wait?condition=removed HTTP/1.1" 200 30 "" "Docker-Client/unknown-version (linux)"
Feb 19 22:04:51 our_host docker-compose[2159010]: java.net.UnknownHostException: www.somehost.com: Temporary failure in name resolution

刚好在aardvark-dns收到SIGHUP后不久，就出现了DNS解析失败，这完全对应上了我们说的阻塞窗口问题。

给你几个可行的解决方向：

• 优先升级aardvark-dns到最新版本：后续版本已经优化了这个逻辑，把刷新改成了非阻塞模式，或者大幅缩短了阻塞时间，能彻底解决这类问题。你可以用podman system info命令查看当前的aardvark-dns版本，然后通过系统包管理器（比如apt、dnf）或者Podman的官方更新渠道升级。
• 临时 workaround（如果暂时没法升级）：
  • 错开不同容器的重启时间，避免短时间内大量容器同时触发aardvark-dns的刷新操作；
  • 切换DNS后端到dnsmasq：修改/etc/containers/containers.conf文件，把dns_backend字段设置为dnsmasq（rootless模式下可能需要额外配置权限，但dnsmasq的刷新逻辑更稳定）。
• 辅助检查：确认你主机/etc/resolv.conf里的DNS服务器是可靠的，有时候外部DNS的延迟会和aardvark-dns的阻塞窗口叠加，加重问题，但核心原因还是前者的实现缺陷。

总结一下：你完全有理由质疑这个行为——这是早期aardvark-dns的缺陷，绝非设计意图。升级到最新版本是最直接有效的解决办法，社区已经针对这个高频场景做了专门优化。

备注：内容来源于stack exchange，提问作者Torque