[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Dec 2022 10:31:33 -0500
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: lookup_name issue with search domains
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.
Cloudflare is lying "this name exists but has no RRs of the type you
requested" when it should be saying "this name does not exist". This
is a consequence of an optimization they did to make it easier for
them to implement DNSSEC dynamically without having to follow the way
NSEC records work right.
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.
