[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200824213618.GM3265@brightrain.aerifal.cx>
Date: Mon, 24 Aug 2020 17:36:18 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Incompatible behaviour of res_query(3) w.r.t. NXDOMAIN
On Mon, Aug 24, 2020 at 10:39:30PM +0200, Daniel Neri wrote:
> On 24 Aug 2020, at 18:43, Rich Felker <dalias@...c.org> wrote:
> >
> > Hmm, I think in this case the "better" might be sufficient that we
> > want to keep it and pressure other implementations to change too. A
> > program performing a lookup where the result is NxDomain may very well
> > want to know whether that's an authenticated (by DNSSEC) NxDomain or
> > one in an insecure zone. Returning an error to the caller with no
> > packet contents discards this critical data.
>
> In that case, it’d be better to add a new resolver API, or implement
> an already existing one that supports this usecase. The other
> implementations I mentioned also support option flags (in global
> state) that can change the behaviour.
>
> res_query(3) is almost as old as DNS itself — it doesn’t seem likely
> that everyone else, both libraries and applications, are going to
> make incompatible changes at this point.
If it were really incompatible behavior I would agree, but the
behaviors aren't incompatible. Either is compatible with the same
underspecified documentation, and a reasonable caller will easily deal
with both -- the nxdomain reply looks very similar to nodata, which it
also needs to be able to handle, except for the different error code
(3 vs 0). A caller can't assume just because res_query succeeded that
ancount>0.
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.
