|
Message-ID: <20221204153132.GV29905@brightrain.aerifal.cx> 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.