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 4056 invoked from network); 4 Dec 2022 15:31:51 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Dec 2022 15:31:51 -0000 Received: (qmail 1277 invoked by uid 550); 4 Dec 2022 15:31:47 -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 1242 invoked from network); 4 Dec 2022 15:31:46 -0000 Date: Sun, 4 Dec 2022 10:31:33 -0500 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20221204153132.GV29905@brightrain.aerifal.cx> References: <20221204040254.pfd3bqjztfw4vrue@localhost> <20221204054559.GB23755@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221204054559.GB23755@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] lookup_name issue with search domains On Sun, Dec 04, 2022 at 06:45:59AM +0100, Markus Wichmann wrote: > On Sun, Dec 04, 2022 at 12:02:54AM -0400, Kenny MacDermid wrote: > > The issue arises when it queries my cloudflare hosted domain (which also > > uses dnssec). That query does not have the reply code flags set to 3. > > Instead it's set to 0. This results in name_from_dns() returning > > EAI_NODATA. > > I think we had that report before. The problem is that cloudflare is > wrong here. DNS response with empty data section and NOERROR status > means the domain name exists, but has no records of the requested type. > If cloudflare is reporting that for a name where that isn't true, they > are making a mistake. > > This is a cloudflare-specific break with the DNS standards (don't ask me > which, though), so we probably won't change musl to deal with this. > Simplest solution for the known-bad actor is to write a proxy server > that turns the wrong answers into correct ones. It's not that we just won't accommodate what Cloudflare is doing, but that Cloudflare is returning data that *means something different* and for which the only correct behavior (that wouldn't break consistency for other results where the provider is using DNS semantics correctly) is what we're doing. Cloudflare is lying "this name exists but has no RRs of the type you requested" when it should be saying "this name does not exist". This is a consequence of an optimization they did to make it easier for them to implement DNSSEC dynamically without having to follow the way NSEC records work right. Rich