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 4DCD05A0271 for ; Fri, 8 Mar 2024 07:06:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709877972; 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=u9cxFvMbDdoRHbEHb/7eWV9w82JPynEruMhqoCK5j5E=; b=PkgRJSthxiVZruAj8YPne7ytoumkVfiQSc3/tqbGUFHbDIR40AIv78ll8QEQ6OuM7LVGZY Qt57eU5Kti/PtWa9XCIWXJhG1qknQxJRZcCHASXG/QbPjR2L6/deKwEstbWpkfTgZBgyOd vPo0m0hhk2ytLc0BIJ2zcY0k+e3Qfsg= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-290-lMuHsDUYNSC0qmqQaVN22Q-1; Fri, 08 Mar 2024 01:06:10 -0500 X-MC-Unique: lMuHsDUYNSC0qmqQaVN22Q-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a45b10aa03cso259326366b.1 for ; Thu, 07 Mar 2024 22:06:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709877969; x=1710482769; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=u9cxFvMbDdoRHbEHb/7eWV9w82JPynEruMhqoCK5j5E=; b=ZrJRlsbTh3IZ2lfMDgexY5T9SyssOZzxwa66ybudlkYySjkrF/Uy9KqB4gWtt64Ed6 lUU3TC17+/J8xuAmvZVjVN/BPiXkUVDcIhnVHivHd4JQiZ9KN22hrSIHMcdGEa3NDLvm hT/vMptV2BlXjes1+FXOcNhc5zCPcp+oN30X6MM8nt+qwUkIF1j80R9Q5iaPkj4qQjJj c2zzpc+TQCC4Yjo3jVLCXMjB98bndZe4K8Ac0MQphFpfAs7T7bJ7oC/HX8WHAAWFq8WO HpxIfavx8aOWw2GTOYtGdp6u1yZcdhvS3Niol1bhZ6MEalQWUQpqp7/Oju1KIyyigBEb Mmtw== X-Gm-Message-State: AOJu0YyUf9ebXV1mm6Wb8+xkEQYC3w+vqpLyt/a489PfZeCYWe0ME6g7 bS6Raa32qQ24Sz8SIylANPGlE9EolDJeavcYVHn16RQ/1eGy4+ARveNf1wVKyrlfl83PIDO1nty AeUH5ixNQCGaXy/RanhND9xlr8gOfsu7/vG2dG8Cg544sPTTTOg== X-Received: by 2002:a17:906:fb81:b0:a45:9e6e:fba1 with SMTP id lr1-20020a170906fb8100b00a459e6efba1mr3334907ejb.15.1709877968766; Thu, 07 Mar 2024 22:06:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IE2/JLVvSlH9wPkW/yS/BSXMkzjSlDE3IORHLnyk3QG+ACBz7e2xmW/c2T3KnynN04DtRWzbw== X-Received: by 2002:a17:906:fb81:b0:a45:9e6e:fba1 with SMTP id lr1-20020a170906fb8100b00a459e6efba1mr3334882ejb.15.1709877968289; Thu, 07 Mar 2024 22:06:08 -0800 (PST) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id b11-20020a1709062b4b00b00a45ef5a9289sm227393ejg.169.2024.03.07.22.06.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2024 22:06:07 -0800 (PST) Date: Fri, 8 Mar 2024 07:05:30 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] conf: Don't warn if nameservers were found, but won't be advertised Message-ID: <20240308070530.6cef401c@elisabeth> In-Reply-To: References: <20240307232551.1828628-1-sbrivio@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.36; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: OVVDAWTHQD3QRBELYAEB2YBMEVJ73CZH X-Message-ID-Hash: OVVDAWTHQD3QRBELYAEB2YBMEVJ73CZH 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 X-Mailman-Version: 3.3.8 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: On Fri, 8 Mar 2024 12:17:13 +1100 David Gibson wrote: > On Fri, Mar 08, 2024 at 12:25:51AM +0100, Stefano Brivio wrote: > > Starting from commit 3a2afde87dd1 ("conf, udp: Drop mostly duplicated > > dns_send arrays, rename related fields"), we won't add to c->ip4.dns > > and c->ip6.dns nameservers that can't be used by the guest or > > container, and we won't advertise them. > > > > However, the fact that we don't advertise any nameserver doesn't mean > > that we didn't find any, and we should warn only if we couldn't find > > any. > > > > This is particularly relevant in case both --dns-forward and > > --no-map-gw are passed, and a single loopback address is listed in > > /etc/resolv.conf: we'll forward queries directed to the address > > specified by --dns-forward to the loopback address we found, we > > won't advertise that address, so we shouldn't warn: this is a > > perfectly legitimate usage. > > > > Reported-by: Paul Holzinger > > Link: https://github.com/containers/podman/issues/19213 > > Fixes: 3a2afde87dd1 ("conf, udp: Drop mostly duplicated dns_send arrays, rename related fields") > > Signed-off-by: Stefano Brivio > > I don't think this is quite the right fix. It makes sense *when* > --dns-forward is specified. However if --dns-forward is *not* > specified, then having only localhost resolvers on the host side means > we really do have nothing the guest can use. So I think we need to > make the behaviour explicitly conditional on the dns_match variable. I was actually about to do that, then I read the text of the warning again: "Couldn't get any nameserver address". If there are just loopback addresses in resolv.conf, and we don't have --dns-forward, is that claim correct? We could get them, we actually parse them, we just don't advertise them. At the same time, we show the user (at least without --quiet) that we don't advertise any server via DHCP/NDP/DHCPv6: that section will be missing. On the other hand, I guess there might be some value in giving the user a hint if they just see name resolution failing. Maybe, if we don't use any nameserver from resolv.conf (or from the command line), we could say "Couldn't use any nameserver address"? > Possibly by making add_dns[46]() accept localhost addresses if > (dns_match && no_map_gw)? What do you mean by "accept"? It already sets .dns_host, no matter what. I don't think we should add loopback addresses to the list we advertise if c->no_map_gw, because they can't be reached anyway. Another alternative would be to automatically advertise the address passed by --dns-forward. But the user can already specify that via --dns, so we'd be actually losing functionality. I was rather pondering to set .dns_host from add_dns[46]() iff it's used (that is, if !IN6_IS_ADDR_UNSPECIFIED(&c->ip[46].dns_match) and return some value there (maybe that's what you meant by "accept")? Then, if any call to add_dns[46]() used any address (advertised or mapped), we wouldn't print any warning. I'm a bit undecided, because we'd make it more complicated for the sake of a warning that doesn't really need to be printed anyway. But again, it might be helpful. -- Stefano