From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
by passt.top (Postfix) with ESMTP id 4E4145A0265
for <passt-dev@passt.top>; Mon, 7 Nov 2022 10:51:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1667814688;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=4rtKjJp3lZncRs7y8nfBRZiLuuOhPFb5q+JFXgY0q58=;
b=FlNsyTLDabhdqut/Tejtwr722yvnVf7XRpQRkQhyA6g69LaPeLBFmqRQa+SMbKQM4QHzbn
yp1O8gEcwpeVekhlHeVIFA4HJhkkjpOkQSFa2Eh0Anv/MWq3IZU9aQyAlbzlbNPnaCdsCb
66ExE+Wivpfkys8rDrp2J/NfTSL7Jzc=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com
[66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
us-mta-448-bMWXVkpVMUW6K9pes-E0RA-1; Mon, 07 Nov 2022 04:51:25 -0500
X-MC-Unique: bMWXVkpVMUW6K9pes-E0RA-1
Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DBF88833AED;
Mon, 7 Nov 2022 09:51:24 +0000 (UTC)
Received: from maya.cloud.tilaa.com (ovpn-208-9.brq.redhat.com [10.40.208.9])
by smtp.corp.redhat.com (Postfix) with ESMTPS id 750E647505F;
Mon, 7 Nov 2022 09:51:24 +0000 (UTC)
Date: Mon, 7 Nov 2022 10:51:21 +0100
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 3/3] udp: Check for answers to forwarded DNS queries
before handling local redirects
Message-ID: <20221107105121.37735a0b@elisabeth>
In-Reply-To: <Y2haq78eQiNkFeBB@yekko>
References: <20221102230443.377446-1-sbrivio@redhat.com>
<20221102230443.377446-4-sbrivio@redhat.com>
<Y2M4lRYMKMdit1l5@yekko>
<20221103074251.60b2898b@elisabeth>
<Y2W6O+7kF1mkV/3d@yekko>
<20221105082223.4a447ac5@elisabeth>
<Y2haq78eQiNkFeBB@yekko>
Organization: Red Hat
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID-Hash: WU3S6GMD3WEQVLXICHP6KIFU7VAFWS6P
X-Message-ID-Hash: WU3S6GMD3WEQVLXICHP6KIFU7VAFWS6P
X-MailFrom: sbrivio@redhat.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: passt-dev@passt.top, Paul Holzinger <pholzing@redhat.com>
X-Mailman-Version: 3.3.3
Precedence: list
List-Id: Development discussion and patches for passt <passt-dev.passt.top>
Archived-At: <>
Archived-At: <https://archives.passt.top/passt-dev/20221107105121.37735a0b@elisabeth/>
List-Archive: <>
List-Archive: <https://archives.passt.top/passt-dev/>
List-Help: <mailto:passt-dev-request@passt.top?subject=help>
List-Owner: <mailto:passt-dev-owner@passt.top>
List-Post: <mailto:passt-dev@passt.top>
List-Subscribe: <mailto:passt-dev-join@passt.top>
List-Unsubscribe: <mailto:passt-dev-leave@passt.top>
On Mon, 7 Nov 2022 12:08:59 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sat, Nov 05, 2022 at 08:22:23AM +0100, Stefano Brivio wrote:
> > On Sat, 5 Nov 2022 12:19:55 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > On Thu, Nov 03, 2022 at 07:42:51AM +0100, Stefano Brivio wrote:
> > > > On Thu, 3 Nov 2022 14:42:13 +1100
> > > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > > >
> > > > > On Thu, Nov 03, 2022 at 12:04:43AM +0100, Stefano Brivio wrote:
> > > > > > Now that we allow loopback DNS addresses to be used as targets for
> > > > > > forwarding, we need to check if DNS answers come from those targets,
> > > > > > before deciding to eventually remap traffic for local redirects.
> > > > > >
> > > > > > Otherwise, the source address won't match the one configured as
> > > > > > forwarder, which means that the guest or the container will refuse
> > > > > > those responses.
> > > > > >
> > > > > > Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> > > > > > ---
> > > > > > udp.c | 17 ++++++++---------
> > > > > > 1 file changed, 8 insertions(+), 9 deletions(-)
> > > > > >
> > > > > > diff --git a/udp.c b/udp.c
> > > > > > index 4b201d3..7c77e09 100644
> > > > > > --- a/udp.c
> > > > > > +++ b/udp.c
> > > > > > @@ -680,8 +680,10 @@ static void udp_sock_fill_data_v4(const struct ctx *c, int n,
> > > > > > src = ntohl(b->s_in.sin_addr.s_addr);
> > > > > > src_port = ntohs(b->s_in.sin_port);
> > > > > >
> > > > > > - if (src >> IN_CLASSA_NSHIFT == IN_LOOPBACKNET ||
> > > > > > - src == INADDR_ANY || src == ntohl(c->ip4.addr_seen)) {
> > > > > > + if (c->ip4.dns_fwd && src == htonl(c->ip4.dns[0]) && src_port == 53) {
> > > > >
> > > > > I guess this is not a newly introduced bug, but for the case of
> > > > > multiple host nameservers, don't you need to check against everything
> > > > > in the ip4.dns[] array, not just entry 0?
> > > >
> > > > No, because that's the only one we're using as target for forwarded
> > > > queries -- and DNS answers we want to check here are only the forwarded
> > > > ones.
> > >
> > > *thinks* .. ok, that makes sense. But if that's the case, won't
> > > ip4.dns[0] be the only entry in ip4.dns[] we use for anything at all?
> > > Can we drop the table and just keep one entry?
> >
> > Now that we have ip{4,6}.dns_send[], yes.
>
> Right, that's what I meant.
>
> > We could rename .dns_send[] back to .dns[] and change the current
>
> Right, I think dns[] is a better name for it.
>
> > .dns[] to .own_dns, or .fwd_dns_target, something like that. Other naming
> > ideas welcome.
>
> Yeah, I find the current dns_fwd name not very illuminating either.
>
> *thinks* does it even make sense for dns_fwd not to be in dns_send?
> We're intercepting queries the guest sends to @dns_fwd, so surely we
> should also be advertising it to the guest.
I wouldn't be so sure of that "surely". In the Podman test case where I
hit this issue, I use Podman to write to /etc/resolv.conf directly, no
DHCP/NDP/DHCPv6 involved, and things work.
That doesn't automatically imply a use case for *not* advertising it,
but we have several ways this can work without advertising anything, so
there are also chances somebody might not want to advertise that in some
obscure use case.
> So what about:
>
> @dns: Primary DNS server advertised to guest - may be a fake
> address we'll intercept
> @dns_extra[]:Additional DNS servers advertised to guest. Must be
> real servers the guest can address without translation
> @host_dns: Host side DNS server (may be localhost or another
> address that's not guest accessible)
>
> The DHCP code advertises both @dns and @dns_extra, and that's the
> *only* place @dns_extra is used.
Also NDP and DHCPv6 use that, and checking one item plus one array in
three places (difficult to share that code path) is uglier than just the
array.
> UDP intercepts outbound packets for @dns and redirects them to
> @host_dns, likewise masquerading inbound packets from @host_dns to
> appear to have come from @dns.
I see the general point, but we would still need a flag to allow users
to disable the redirection.
Given that, I'd rather go with dns, host_dns, and fwd_dns, it looks
simpler.
--
Stefano