Date: Mon, 5 Dec 2022 08:26:05 -0500 From: Rich Felker <dalias@...c.org> To: Kenny MacDermid <kenny@...dermid.ca> Cc: musl@...ts.openwall.com Subject: Re: 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. > > Either way it's unfortunate that musl handles this differently than > others like glibc, the BSD libc, and Go. > > : 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.