mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Incompatible behaviour of res_query(3) w.r.t. NXDOMAIN
Date: Mon, 24 Aug 2020 18:13:43 -0400	[thread overview]
Message-ID: <20200824221343.GO3265@brightrain.aerifal.cx> (raw)
In-Reply-To: <87eenvya2r.fsf@mid.deneb.enyo.de>

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

      reply	other threads:[~2020-08-24 22:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-23 21:31 Daniel Neri
2020-08-24 16:16 ` Rich Felker
2020-08-24 16:43   ` Rich Felker
2020-08-24 20:39     ` Daniel Neri
2020-08-24 21:36       ` Rich Felker
2020-08-24 21:04     ` Florian Weimer
2020-08-24 21:32       ` Rich Felker
2020-08-24 21:51         ` Daniel Neri
2020-08-24 22:09           ` Rich Felker
2020-08-25  3:26             ` Rich Felker
2020-08-25 13:56               ` Daniel Neri
2020-08-24 22:04         ` Florian Weimer
2020-08-24 22:13           ` Rich Felker [this message]

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=20200824221343.GO3265@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --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).