From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SUBJ_OBFU_PUNCT_FEW,SUBJ_OBFU_PUNCT_MANY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10776 invoked from network); 24 Aug 2020 22:13:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Aug 2020 22:13:59 -0000 Received: (qmail 3339 invoked by uid 550); 24 Aug 2020 22:13:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3321 invoked from network); 24 Aug 2020 22:13:55 -0000 Date: Mon, 24 Aug 2020 18:13:43 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200824221343.GO3265@brightrain.aerifal.cx> References: <5232EC15-7E60-4D1F-BF3B-C31BFF998C06@rb67.eu> <20200824161646.GH3265@brightrain.aerifal.cx> <20200824164326.GI3265@brightrain.aerifal.cx> <87mu2jycum.fsf@mid.deneb.enyo.de> <20200824213215.GL3265@brightrain.aerifal.cx> <87eenvya2r.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eenvya2r.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Incompatible behaviour of res_query(3) w.r.t. NXDOMAIN On Tue, Aug 25, 2020 at 12:04:44AM +0200, Florian Weimer wrote: > * Rich Felker: > > > On Mon, Aug 24, 2020 at 11:04:49PM +0200, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > 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. > >> > >> Isn't this the behavior you'd get with res_send? > >> > >> I think such error translation is precisely the point of the res_query > >> convenience function (along with the implicit construction of the > >> query packet). > > > > Does such a distinction exist? > > Yes, I think so. It's the behavior of the BIND 4 era stub resolver > code. OK. The man pages (and glibc docs? not sure) don't seem to document this, so we should probably try to get them fixed too. The closest I can find is the text that: "In the case of an error return from res_nquery(), res_query(), res_nsearch(), res_search(), res_nquerydomain(), or res_querydomain(), the global variable h_errno (see gethostbyname(3)) can be consulted to determine the cause of the error." which could be interpreted as saying the same errors are specified to happen (does this mean NODATA shoudl also be an error rather than a success return?), but it doesn't make clear that nxdomain and noerror are not errors for res_send etc. Rich