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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24553 invoked from network); 19 Sep 2022 17:18:26 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 17:18:26 -0000 Received: (qmail 19522 invoked by uid 550); 19 Sep 2022 17:18:23 -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 19490 invoked from network); 19 Sep 2022 17:18:22 -0000 Date: Mon, 19 Sep 2022 13:18:09 -0400 From: Rich Felker To: Luca BRUNO Cc: musl@lists.openwall.com Message-ID: <20220919171808.GR9709@brightrain.aerifal.cx> References: <20220831235914.GA19125@brightrain.aerifal.cx> <20220901124512.GA21934@brightrain.aerifal.cx> <20220901160318.67d15b3f@ephyra> <20220901180153.GB21934@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220901180153.GB21934@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] musl resolver handling of "search ." in /etc/resolv.conf On Thu, Sep 01, 2022 at 02:01:53PM -0400, Rich Felker wrote: > On Thu, Sep 01, 2022 at 04:03:18PM +0000, Luca BRUNO wrote: > > On Thu, 1 Sep 2022 08:45:12 -0400 > > Rich Felker wrote: > > > > > "search ." by itself is a semantically a no-op. It specifies a single > > > search domain that's the DNS root, which is exactly what gets queried > > > with no search at all. systemd is writing this into resolv.conf > > > because of a glibc "misbehavior" (to put it lightly) where, in the > > > absence of any search directive, it defaults to searching the domain > > > of the system hostname (so hostname=foo.example.com would implicitly > > > search example.com, which is obviously wrong to do, and systemd is > > > trying to suppress that). But it would also cause failing lookups to > > > be performed in duplicate, unless there's logic to suppress the final > > > non-search lookup when root was already searched explicitly. > > > > While tracking down this musl bug, I empirically observed from > > network traces that glibc does apply such de-duplication logic under the > > same configuration. > > That is, it performs the root-anchored query in the specified order, and > > in case of a negative response it does *not* perform the query again as > > it would otherwise do for the final fallback case. > > Thanks! This is good to know. > > > > > > There are 3 options I see: > > > > > > > > > > - Actually support it as a search. This is *bad* behavior, but at > > > > > least unlike the version of this behavior musl explicitly does > > > > > not implement, it was explicitly requested by the user. Except > > > > > that it wasn't, because systemd is just putting it in everyone's > > > > > resolv.conf.. > > > > > > > > > > - Skip it completely. Never search root; wait for the end of the > > > > > search list and query root as always. > > > > > > > > > > - End search on encountering it and go directly to the post-search > > > > > query at root. > > > > > > > > > > Anyone care strongly about this one way or another? > > > > From my observations, option 1 is consistent with other libc's behavior. > > But it has the above caveat that it needs additional caching to > > avoid duplicate root-queries on negative responses. > > If it isn't too invasive to implement, that would be my preferred one. > > I'm not clear what additional caching you have in mind. AFAICT the > search loop can just set a flag if it searched root already, and the > final root query can be skipped if it's reached and the flag is set. > > > Option 2 looks somehow reasonable too. The skewed order would be > > a bit surprising, but it can be documented and it's unlikely to affect > > many real-world usages. > > If we go this route, I think the way to document it would be that > search list entries are strings of one or more label, and that > malformed ones (including zero-length, over-length, etc.) are ignored. OK, I've looked at it in more detail now and there are actually multiple layers to this bug, separate from the search logic itself: 1. res_mkquery does not error out on multiple consecutive dots in the name, but instead produces a malformed query packet. There are likely other error conditions it doesn't handle right, too. 2. name_from_dns wrongly returns EAI_NONAME (inhibiting further search) rather than 0 when res_mkquery produces an error. This causes entries in the search list that cannot exist as valid domain names (due to invalid characters, exceeding max total length or label length, etc.) to break the whole search when they should conclusively prove nonexistence of the attempted name and let the search continue. With these two fixed, we will "automatically" get the option 2 behavior, since concatenating name+"."+search where search is "." will produce a malformed name ending in double dot. If we want to later change this to the option 1 behavior, we can make the search logic remove final dot itself. I'll work on patches for the above two issues. Rich