pasta - Multiple DNS servers in resolv.conf
Hi Stefano, I have 2 DNS servers listed in the host /etc/resolv.conf - useful during a failure or maintenance of the primary server (even if fallback to the send server is much slower). Can you please advise the best way to get podman containers using pasta to also have the 2 DNS servers? I note that if I don’t provide a —dns-forward option then the resolv.conf file is mapped through from the host, with an additional nameserver 169.254.1.1 added as the first entry above the ones in the host file. Thanks in advance. -- From: Ben Woods
Hi Ben,
On Fri, 25 Apr 2025 17:13:58 +0800
"Ben Woods"
Hi Stefano,
I have 2 DNS servers listed in the host /etc/resolv.conf - useful during a failure or maintenance of the primary server (even if fallback to the send server is much slower).
Can you please advise the best way to get podman containers using pasta to also have the 2 DNS servers?
There's no way to do that directly (and you _should_ not need it, I think), because pasta doesn't really speak DNS (for simplicity / security). It can just forward what looks like DNS over TCP and UDP back and forth, but it's not aware of single queries or responses, so it can't really "fall back" to a secondary server. However:
I note that if I don’t provide a —dns-forward option then the resolv.conf file is mapped through from the host, with an additional nameserver 169.254.1.1 added as the first entry above the ones in the host file.
...that will map to whatever resolver you have as first resolver on the host. The other resolvers are there as well, though, so the fall back should work exactly as it does on the host. That's why I think you shouldn't need an explicit fallback handled by pasta. We have / had an issue though, and it was just fixed by this series: https://archives.passt.top/passt-dev/20250417015543.457310-1-david@gibson.dr... and somewhat described / analysed here: https://archives.passt.top/passt-dev/Z_3ukwUuG6kHwUW5@zatzit/ where we wouldn't send ICMP errors back to the container for unresponsive DNS resolvers. As a result, resolvers needed to time out instead of failing right away, and if your application timed out before the resolver itself, then you wouldn't see the fallback in action at all. This fix will be available in the next release (probably in a couple of days, might be a couple of weeks). -- Stefano
Thanks for the detailed reply Stefano - very helpful to come up to speed on the recent history. On Mon, 28 Apr 2025, at 9:05 PM, Stefano Brivio wrote:
Hi Ben,
On Fri, 25 Apr 2025 17:13:58 +0800 "Ben Woods"
wrote: Hi Stefano,
I have 2 DNS servers listed in the host /etc/resolv.conf - useful during a failure or maintenance of the primary server (even if fallback to the send server is much slower).
Can you please advise the best way to get podman containers using pasta to also have the 2 DNS servers?
There's no way to do that directly (and you _should_ not need it, I think), because pasta doesn't really speak DNS (for simplicity / security).
It can just forward what looks like DNS over TCP and UDP back and forth, but it's not aware of single queries or responses, so it can't really "fall back" to a secondary server. However:
I note that if I don’t provide a —dns-forward option then the resolv.conf file is mapped through from the host, with an additional nameserver 169.254.1.1 added as the first entry above the ones in the host file.
...that will map to whatever resolver you have as first resolver on the host. The other resolvers are there as well, though, so the fall back should work exactly as it does on the host. That's why I think you shouldn't need an explicit fallback handled by pasta.
We have / had an issue though, and it was just fixed by this series:
https://archives.passt.top/passt-dev/20250417015543.457310-1-david@gibson.dr...
and somewhat described / analysed here:
https://archives.passt.top/passt-dev/Z_3ukwUuG6kHwUW5@zatzit/
where we wouldn't send ICMP errors back to the container for unresponsive DNS resolvers.
As a result, resolvers needed to time out instead of failing right away, and if your application timed out before the resolver itself, then you wouldn't see the fallback in action at all.
This fix will be available in the next release (probably in a couple of days, might be a couple of weeks).
-- Stefano
-- From: Ben Woods ben@woods.am
participants (2)
-
Ben Woods
-
Stefano Brivio