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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27067 invoked from network); 4 Dec 2022 23:04:33 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Dec 2022 23:04:33 -0000 Received: (qmail 1869 invoked by uid 550); 4 Dec 2022 23:04:29 -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 1837 invoked from network); 4 Dec 2022 23:04:29 -0000 Date: Sun, 4 Dec 2022 19:04:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=macdermid.ca; s=key1; t=1670195057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=M/Ne8lAMY2MyEFmMVpr/+cnuGGeAXFdDXan5pDx0iNg=; b=019GJsQPSui+K6/PuxyA79uPFC53TGSCU41uT8hBEcaq2CXsnaE4JELuyhl/pSFGfz0dsq sIcg3m68HOJiuZYC/lkVt5KtHyburevgRW+93PUwp1/7xECfNQ3F43A/ltEi14IQlPKtyb xLJbBi2X0a63vHOUCU3t4B9GuHT/3u0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kenny MacDermid To: musl@lists.openwall.com Message-ID: <20221204230410.bf52c3xjs44xhgfo@localhost> References: <20221204040254.pfd3bqjztfw4vrue@localhost> <20221204054559.GB23755@voyager> <20221204153132.GV29905@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221204153132.GV29905@brightrain.aerifal.cx> X-Migadu-Flow: FLOW_OUT Subject: Re: [musl] lookup_name issue with search domains On Sun, Dec 04, 2022 at 10:31:33AM -0500, Rich Felker wrote: > 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. Well, I guess the “It’s always DNS” meme strikes again. Do you happen to have a reference to the RFC that Cloudflare isn't following by returning what they do? The blog post I found on the topic /claims/ they're compliant[1]. Either way it's unfortunate that musl handles this differently than others like glibc, the BSD libc, and Go. [1]: https://blog.cloudflare.com/black-lies/