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 18982 invoked from network); 5 Dec 2022 13:26:23 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Dec 2022 13:26:23 -0000 Received: (qmail 15874 invoked by uid 550); 5 Dec 2022 13:26:18 -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 15842 invoked from network); 5 Dec 2022 13:26:17 -0000 Date: Mon, 5 Dec 2022 08:26:05 -0500 From: Rich Felker To: Kenny MacDermid Cc: musl@lists.openwall.com Message-ID: <20221205132604.GW29905@brightrain.aerifal.cx> References: <20221204040254.pfd3bqjztfw4vrue@localhost> <20221204054559.GB23755@voyager> <20221204153132.GV29905@brightrain.aerifal.cx> <20221204230410.bf52c3xjs44xhgfo@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221204230410.bf52c3xjs44xhgfo@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] lookup_name issue with search domains On Sun, Dec 04, 2022 at 07:04:10PM -0400, Kenny MacDermid wrote: > 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/ You're not going to find anything saying they're not "compliant" because that's not the problem. The responses they're given are well-formed, consistent, and not breaking any rules of DNS from the perspective of someone making queries who does not have any prior expectation for what the queried zones contain. The problem is just that the responses *mean something different thant what you intended*. As an analogy, you could imagine a DNS provider adding some sort of TXT records to every name in your zone. Nothing about DNS says they can't -- these are valid records that can exist anywhere -- but they'd be serving something different than what you asked them to. In this case, Cloudflare is effectively making *every possible* name under your zone exist, but with no RRs defined for it unless you provided some. This is contrary to your intent that names you didn't define simply not exist. The solutions here are basically: - Turn off DNSSEC (not good), or - Use a different DNS provider that doesn't munge your zones, or - Don't use any functionality that depends on ability to distinguish NODATA from NxDomain for the names under your zone, and accept that everything is going to be NODATA. (In particular, don't use "search" on it.) If you want to search out other sources on the topic, "nodata vs nxdomain" is a good query. Rich