From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 4CCB55A0082 for ; Mon, 23 Jan 2023 07:26:05 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4P0g8n64PHz4y0Q; Mon, 23 Jan 2023 17:26:01 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1674455161; bh=yo2nGyyRvk4N5JqYKArC+P+JgMJOgE6wDxMGxLLFfos=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KLw4q6bW6eSesmBMN+KTUgrVIxjjVNB95GvnHfzXGxvTE8IA06Eb0H0M5dELCSB/G v5X8Z8acH9eGj576UeTZENmX40p0bLzuORzZC0R7651MkniyQQOzgChYE9XdGk5JQ8 6/3SHD84ntgg1dhB6T1Ho8Ax00/gNWWwNNErruiI= Date: Mon, 23 Jan 2023 17:20:13 +1100 From: David Gibson To: Stefano Brivio Subject: Re: Improved handling of changing DNS resolvers Message-ID: References: <20230121104703.3ebcc753@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uBjjzmmA7FEQfJXO" Content-Disposition: inline In-Reply-To: <20230121104703.3ebcc753@elisabeth> Message-ID-Hash: BNJZCFLOTPMV3FZ5VOHFUHXSVWUCSS3R X-Message-ID-Hash: BNJZCFLOTPMV3FZ5VOHFUHXSVWUCSS3R X-MailFrom: dgibson@gandalf.ozlabs.org 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: Noah Gold , passt-dev@passt.top X-Mailman-Version: 3.3.3 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --uBjjzmmA7FEQfJXO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 21, 2023 at 10:47:03AM +0100, Stefano Brivio wrote: > Hi Noah, >=20 > Sorry for the delay, I didn't check pending mailing list posts for a > couple of days. Comments below: >=20 > On Tue, 17 Jan 2023 11:50:50 -0800 > Noah Gold wrote: >=20 > > Hi folks, > >=20 > > libslirp and Passt have different approaches to sharing DNS resolvers w= ith > > the guest system, each with their own benefits & drawbacks. On the libs= lirp > > project, we're discussing [1] how to support DNS failover. Passt alread= y has > > support for this, but there is a drawback to its solution which preven= ts us > > from taking a similar approach: the resolvers are read exactly once, so= if the > > host changes networks at runtime, the guest will not receive the updated > > resolvers and thus its connectivity will break. So, passt/pasta kinda-sorta binds itself to a particular host interface, so DNS won't be the only issue if the host changes network. For one thing, at least by default the guest gets the same IP as the host, so if the host IP changes the guest will get out of sync. We'll mostly cope with that ok, but there will be some edge cases which will break (most obviously if after the network change the guest wants to talk to something at the host's old address / its current address). > Right -- the main motivation behind this (other than simplicity) is that > we can close /etc/resolv.conf before sandboxing. >=20 > However, we could keep a handle on it, just like we do for PID and pcap > files, while still unmounting the filesystem. >=20 > And we could also use inotify to detect changes I guess -- we do the > same to monitor namespaces in pasta mode (see pasta_netns_quit_init()). All true, but I'm not sure those are actually the most pressing issues we'll face with a host network change. > > libslirp's current approach is to DNAT a single address exposed to the = guest > > to one of the resolvers configured on the host. The problem here is tha= t if that > > one resolver goes down, the guest can't resolve DNS names. We're > > considering changing so that instead of a single address, we expose a s= et of > > MAXNS addresses, and DNAT those 1:1 to the DNS resolvers registered with > > the host. Because the DNAT table lives on the host side, we can refresh= the > > guest's resolvers whenever the host's resolvers change, but without the= need to > > expire a DHCP lease (even with short leases, the guest will still lose > > connectivity > > for a time). > >=20 > > Does this sound like an approach Passt would be open to adopting as wel= l? >=20 > Yes, definitely, patches would be very welcome. Hm, that's doesn't fit that easily into the passt model. For the most part we don't NAT at all, we only have a couple of special cases where we do. Because of that the problem with adding any extra NAT case is address allocation. Currently we use the host's gateway address, which mostly works but is a bit troublesome. I have some ideas I think will work better, but those don't necessarily get us more available addresses. > Note that David (Cc'ed) is currently working on a generalised/flexible > address mapping mechanism, some kind of (simple) NAT table as far as I > understood it. That's a bit overstating it. I'm making our current single NAT case (translating host side loopback to gateway address on the guest) more configurable. I have plans (or at least ideas) for a more generalized NAT mechanism, but I'm really not implementing that yet. What I'm doing now is kind of a soft prerequisite for that rework though (as well as useful in its own right). > This might even address your DNS idea already, I'm not sure, I'd wait > for him to comment. Hadn't considered specifically that model, but it's a reasonbly natural extension of it (address allocation is still a complication). I'll certainly consider this case when I do more on this. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --uBjjzmmA7FEQfJXO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoULxWu4/Ws0dB+XtgypY4gEwYSIFAmPOJwMACgkQgypY4gEw YSIZjw//eYQZTU9E6H5Sdnn3Mg9zRBeFR3qP76XqT7UmnfnAMY3YrD1i1Oy0YCEe Bb6v1QZw8zWwPfQRM2Fno4NSlpzLeZCcf41pgZ8LRFCYlN4gv43MQc3ADJBZdgKV tI+JfaugCSNNpoTskfHBnpXhUnGsxQxMwT3LJfGby1cO8FOVT81l5U/VJf234Jjm OVdMc4fYPzXVvWundmMJfR14H7u/8mwl5m9nb6x5NgEuaDAJRGnqVVbd52D4XBwT g1Ud/BcC8JNhO0wX8mRNFzxoHjfnZ9rKYYQK3SQCDO9Elw4oGplWF4buUqn1Og/b 4lwdTJ+DdzYd+8I3EYkB8/+7dcV8kwHN1PtbLOD6fILmyRh8JRxMTa/trCnIm60s DqgOuAp1TaRqYZSdl5ZcbWNi0HEeNeF8J+P4wiaasHAT3MmZFi29iPuXUAspkyI9 G3OrjyYqvICvYEvumJcG2ZRNfhVAaM+TS60Sa0y+fg+00lZNDsPeaSg61ydgicQr G8TaKQRwGy9UThGFgM5VVtswJEPZkpiI+826udd8wL4KR+IsmNaXiro4Vm/OjPN/ 5rSAzRj4lysXYNNP5vJC97ALXsXlTIp45vhksuxRlTRZJgu8kK+hkz5N32pkb2pt O1Utk4+rJZFPeQ9+FVzrQAekMkNPeQXpX1TJT63YpJ1Y6NUONyc= =FFbU -----END PGP SIGNATURE----- --uBjjzmmA7FEQfJXO--