From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26352 invoked from network); 27 Jun 2023 14:36:20 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2023 14:36:20 -0000 Received: (qmail 30530 invoked by uid 550); 27 Jun 2023 14:36:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30493 invoked from network); 27 Jun 2023 14:36:16 -0000 Date: Tue, 27 Jun 2023 10:36:04 -0400 From: Rich Felker To: Rob de Wit Cc: musl@lists.openwall.com Message-ID: <20230627143604.GT4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Clarification on the NOERROR resolving choices On Tue, Jun 27, 2023 at 07:12:51AM -0700, Rob de Wit wrote: > Hi > > I ran into some issues lately and found this in the mailing list archive > https://www.openwall.com/lists/musl/2019/05/30/3 > > The problem I had was with Alpine containers that suddenly failed resolving > any hostname. I ended up tracing it back to a change I made in a domain > that was in the "search" fiels in /etc/resolv.conf. The change was a > wildcard TXT field. So when the resolver was resolving > ... it received an NOERROR reply. This > indicates there is a record but just not a "A" or "AAAA" one. Perfectly > valid as far as I know, but the resolver then quits the search. This is the intended behavior. When reaching a name that exists, the search stops and uses that result. Otherwise the search outcome will be unstable depending on factors like which address family was queried. In theory, that particular case could be precluded by always performing both A and AAAA queries, even when only one was requested by the caller, but users would likely not be happy with this behavior, especially if it meant waiting for an uncached AAAA result that's not even desired or erroring out in sloppy IPv4-only environments where something is setup to make the AAAA fail. But not even getting into that specific case, it's just having consistent high level semantics. Search continues if and only if the attempted name does not exist. > Maybe someone here can clarify this behaviour, because from the referred > thread in the mailing list I get that this is caused by malfunctioning DNS, > but in my case I don't think it is. It's not "malfunctioning", just returning something whose semantics mismatch what you want. > Right now our options are: > > - adjusting ndots in resolv.conf - but we actually use the search path Setting ndots greater than 1 always gives undesirable behaviors like adding potentially substantial delay when looking up a name that was already fully qualified, independently of whether you're using musl or something else. It really should be treated only as a way to support legacy setups, not part of new designs. > - adding a dot at the end - this can only work if we know up front we > don't want the search path > - replacing Alpine with some libc-based image - this involves many > changes > - not to do it again (adding wildcard for something other than A or AAAA > records) It's not a matter of whether it's something other than A or AAAA; just that you have a wildcard in your search domain path. This will never give acceptable results unless your goal is to intercept all lookups and have them return the same thing (either NODATA or a fixed address). Rich