[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221205132604.GW29905@brightrain.aerifal.cx>
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[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
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.
