From: Rich Felker <dalias@libc.org>
To: Kenny MacDermid <kenny@macdermid.ca>
Cc: musl@lists.openwall.com
Subject: Re: [musl] lookup_name issue with search domains
Date: Mon, 5 Dec 2022 08:26:05 -0500 [thread overview]
Message-ID: <20221205132604.GW29905@brightrain.aerifal.cx> (raw)
In-Reply-To: <20221204230410.bf52c3xjs44xhgfo@localhost>
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
next prev parent reply other threads:[~2022-12-05 13:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-04 4:02 Kenny MacDermid
2022-12-04 5:45 ` Markus Wichmann
2022-12-04 15:31 ` Rich Felker
2022-12-04 23:04 ` Kenny MacDermid
2022-12-05 13:26 ` Rich Felker [this message]
2022-12-05 20:11 ` Kenny MacDermid
2022-12-05 22:25 ` Quentin Rameau
2022-12-06 5:19 ` Kenny MacDermid
2022-12-06 9:57 ` Quentin Rameau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221205132604.GW29905@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=kenny@macdermid.ca \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).