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 27594 invoked from network); 27 Jun 2023 15:22:26 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2023 15:22:26 -0000 Received: (qmail 32044 invoked by uid 550); 27 Jun 2023 15:22: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 32009 invoked from network); 27 Jun 2023 15:22:22 -0000 Date: Tue, 27 Jun 2023 11:22:12 -0400 From: Rich Felker To: Rob de Wit Cc: musl@lists.openwall.com Message-ID: <20230627152212.GU4163@brightrain.aerifal.cx> References: <20230627143604.GT4163@brightrain.aerifal.cx> 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 05:05:13PM +0200, Rob de Wit wrote: > Op di 27 jun 2023 om 16:36 schreef Rich Felker : > > > > > 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 > > > > Thanks for the explanation and quick response. > > I'm not sure I agree that NOERROR is a valid response if some other record > is queried for. I mean most other implentations do the other thing so even > if this is the correct way, a lot of compatibility is broken, but that is > up to you guys. If you didn't have a search going on and just queried the concatenated name directly yourself, what you're calling NOERROR (I'd call this NODATA to distinguish from rcode==NOERROR with ancount>0, the more "normal" success condition) is the expected result. It's a successful result that means the thing you queried exists, and just has 0 RRs of the requested type. Indeed other implementations do continue search on NODATA and sometimes even on other more-transient conditions, which can produce really inconsistent results, sometimes even under attacker control. musl's stub resolver has always aimed to avoid that kind of thing, and when search support was added (with much hesitation/reservation) many years ago, the compromise was that it would preserve the kinds of consistency our resolver aims for and not replicate every behavior of glibc or other historic implementations. > This last bit really shows where we went wrong. I'll remember not to use a > wildcard without a proper subdomain (lightly). If I had a wildcard A in the > domain (without subdomain) it would have broken even more by resulting in > the same address for every host tried. Exactly. Rich