From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by passt.top (Postfix) with ESMTPS id 12D3B5A005E for ; Tue, 31 Jan 2023 01:11:51 +0100 (CET) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-4c24993965eso182299427b3.12 for ; Mon, 30 Jan 2023 16:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qWzfO9nt6QB4LXDr5I77qyMbMi76ibGBoYQ8Ar6XGG4=; b=jTTP3oKvSzT2jk8nJsXW+5s+O8IN39fxbpKXGsLqVdl9TeJ9ZzrvKd6faRSQ0x7g1i cV9JVjKFW5L8zCPbEJ8IWyUUpDmXtsICKP3G5WvfGK1jxpmyn/vKyPUNmMw0sjqzQpQE BA/Z51+U3udWUi9nWc7QuM7eyM8OAkeIYy9TG1owZ51rcvjIxTzncNAv+Zpj4BI4fmZA AvVb2aEArEkdnhXMCkKjqIEEeZTlEkBIgsNPhoainwXZfJo6UCGAjbGANfUEm5Hmcf7m QQSUmCo/c4L+W2t6u7dmMxqlb0OSqTK88j4SigdiqH/J3tojkiDeC59r2jkOst3UlI03 amEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qWzfO9nt6QB4LXDr5I77qyMbMi76ibGBoYQ8Ar6XGG4=; b=w24YwSHjX50+6VRvJ1bQ2ctkaEPLKyCHAEI2kzbhaaywxvsmc2kWXWmU1A1jyxzRKy LwLQrKICJ/c+z1vHduxDehEll2PI7WVlgZcbWiOYfA3RqUAXvX7CJpbabQKv8T2Xm5G1 E4ZyUjDHSB5yUfDxFa8kjtJL9oJ0i9i3Y4CFWsyiSuIGPE31zK4gkPehnfD0zNWQ23ZZ JjWYUzqrcM8B4iD0RFZcwbRI4R6lB8iNcAYi8XXx+UfWN3nU7VDi/RT6KNiwMWA8J3Dy YMIhAf7RTwofgkiQMWi3upmeXJNE7/Mh9jSvdpU815vQNSTyea1leEWuekUybh4jdgft qxUQ== X-Gm-Message-State: AO0yUKWBpvuz6fG9hzYDJSke1ybNrE49xJ428kleNqfRSQEzfFF0oGNO JOQMNm46i3p2erzswYSvCc8ASut/vaIhfOFiXT2F4g== X-Google-Smtp-Source: AK7set9vO5TyRJE2lUAHrgl09jIZwm24URO9wQN6c5xUt335VvgrF5JPXnYsPZrBJkK9WGOOM2aGdQRYVJ+z/WyfxK8= X-Received: by 2002:a81:ad55:0:b0:506:644b:c30 with SMTP id l21-20020a81ad55000000b00506644b0c30mr2564425ywk.109.1675123909711; Mon, 30 Jan 2023 16:11:49 -0800 (PST) MIME-Version: 1.0 References: <20230121104703.3ebcc753@elisabeth> In-Reply-To: From: Noah Gold Date: Mon, 30 Jan 2023 16:11:38 -0800 Message-ID: Subject: Re: Improved handling of changing DNS resolvers To: David Gibson Content-Type: text/plain; charset="UTF-8" X-MailFrom: nkgold@google.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: PXZFMJTPDK27WI4VBAUWW5RLUZXRGRMW X-Message-ID-Hash: PXZFMJTPDK27WI4VBAUWW5RLUZXRGRMW X-Mailman-Approved-At: Tue, 31 Jan 2023 13:49:05 +0100 CC: Stefano Brivio , 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: Sorry for the delay, I've been really busy this past week. On Sun, Jan 22, 2023 at 10:26 PM David Gibson wrote: > > On Sat, Jan 21, 2023 at 10:47:03AM +0100, Stefano Brivio wrote: > > Hi Noah, > > > > Sorry for the delay, I didn't check pending mailing list posts for a > > couple of days. Comments below: > > > > On Tue, 17 Jan 2023 11:50:50 -0800 > > Noah Gold wrote: > > > > > Hi folks, > > > > > > libslirp and Passt have different approaches to sharing DNS resolvers with > > > the guest system, each with their own benefits & drawbacks. On the libslirp > > > project, we're discussing [1] how to support DNS failover. Passt already has > > > support for this, but there is a drawback to its solution which prevents 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. > > > > However, we could keep a handle on it, just like we do for PID and pcap > > files, while still unmounting the filesystem. > > > > 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 that 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 set 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). > > > > > > Does this sound like an approach Passt would be open to adopting as well? > > > > 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. For libslirp we have the guest on a private subnet, so pulling addresses from that pool is pretty easy. For passt is the issue that there is no address range, or that the infrastructure to allocate from the range just doesn't exist yet? When you say "we use the host's gateway address", what is it used for exactly? (I didn't follow the loopback example below.) > > > 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. It sounds like there might be a path to using NAT, but it's not something that would be ready soon. Given that, would there be long term concerns with using NAT for DNS in the way proposed here? I understand we can't implement it now, but I'd like to understand if it's an approach we would still rather avoid, even long term. > > -- > 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 On Wed, Jan 25, 2023 at 9:55 AM Stefano Brivio wrote: > > On Mon, 23 Jan 2023 17:20:13 +1100 > David Gibson wrote: > > > On Sat, Jan 21, 2023 at 10:47:03AM +0100, Stefano Brivio wrote: > > > Hi Noah, > > > > > > Sorry for the delay, I didn't check pending mailing list posts for a > > > couple of days. Comments below: > > > > > > On Tue, 17 Jan 2023 11:50:50 -0800 > > > Noah Gold wrote: > > > > > > > Hi folks, > > > > > > > > libslirp and Passt have different approaches to sharing DNS resolvers with > > > > the guest system, each with their own benefits & drawbacks. On the libslirp > > > > project, we're discussing [1] how to support DNS failover. Passt already has > > > > support for this, but there is a drawback to its solution which prevents 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). > > Noah, by the way, if your usage for DNS failover is related to a > virtual machine being migrated to another host with different > addressing, mind that you could simply tell qemu to connect to a new > instance of passt. That's something you can't do with libslirp. It's not related to machine migration, though that's another interesting case with similar constraints. The use case I'm thinking about is for a mobile device that may experience network changes as part of its normal operation (e.g. changing wifi networks). > > Would that solve your problem, or your issue is specifically related to > DNS failover without any VM migration playing a role? It's not related to migration, but I wonder whether there's an idea there which could be used. The approach I was taking was to make the network component resilient to network changes. But another option is to detect network changes and restart the network component. libslirp still needs a way to support exposing multiple servers though, and I wonder whether we would want to require library consumers to write network awareness into their applications as opposed to solving it for them. > > -- > Stefano >