public inbox for passt-user@passt.top
 help / color / mirror / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: "Ben Woods" <pasta@ben.woods.am>
Cc: passt-user@passt.top
Subject: Re: pasta - Multiple DNS servers in resolv.conf
Date: Mon, 28 Apr 2025 15:05:07 +0200	[thread overview]
Message-ID: <20250428150507.093cc8d5@elisabeth> (raw)
In-Reply-To: <d45670f0-75a0-4ec0-afde-c64c7f031d8f@app.fastmail.com>

Hi Ben,

On Fri, 25 Apr 2025 17:13:58 +0800
"Ben Woods" <pasta@ben.woods.am> 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.dropbear.id.au/

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


       reply	other threads:[~2025-04-28 13:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d45670f0-75a0-4ec0-afde-c64c7f031d8f@app.fastmail.com>
2025-04-28 13:05 ` Stefano Brivio [this message]
2025-04-28 13:13   ` pasta - Multiple DNS servers in resolv.conf Ben Woods

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250428150507.093cc8d5@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=passt-user@passt.top \
    --cc=pasta@ben.woods.am \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).