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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27313 invoked from network); 19 Sep 2022 22:26:22 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 22:26:22 -0000 Received: (qmail 10107 invoked by uid 550); 19 Sep 2022 22:26:20 -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 10075 invoked from network); 19 Sep 2022 22:26:19 -0000 Date: Mon, 19 Sep 2022 18:26:07 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20220919222607.GD9709@brightrain.aerifal.cx> References: <20220919221402.GC9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220919221402.GC9709@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] EAI_NODATA in musl On Mon, Sep 19, 2022 at 06:14:03PM -0400, Rich Felker wrote: > I just posted on libc-coord about an idea that sounded good, and it > turns out glibc and nearly everyone else have had it for a long time: > > https://www.openwall.com/lists/libc-coord/2022/09/19/2 > > I'd like to bring the same to musl, even though it's not standardized > yet, since it's a clear candidate for standardization and solves a > major problem with the libc DNS API, namely inability to distinguish > NxDomain from NODATA. > > Aside from that, it should help justify musl's distinguishing of these > two (very different) results in how search domain fallbacks work and > how results for one of the A or AAAA erroring out get handled. Our > misleadingly reporting "name exists but has no address" as "name > doesn't exist" has made it hard for folks to understand why we don't > keep going on the search when "name does not exist". > > Draft patch attached, untested. > > diff --git a/include/netdb.h b/include/netdb.h > index d096c781..3af065e2 100644 > --- a/include/netdb.h > +++ b/include/netdb.h > @@ -44,6 +44,7 @@ struct addrinfo { > #define EAI_NONAME -2 > #define EAI_AGAIN -3 > #define EAI_FAIL -4 > +#define EAI_NODATA -5 > #define EAI_FAMILY -6 > #define EAI_SOCKTYPE -7 > #define EAI_SERVICE -8 > diff --git a/src/network/gai_strerror.c b/src/network/gai_strerror.c > index 9596580e..56b71503 100644 > --- a/src/network/gai_strerror.c > +++ b/src/network/gai_strerror.c > @@ -6,7 +6,7 @@ static const char msgs[] = > "Name does not resolve\0" > "Try again\0" > "Non-recoverable error\0" > - "Unknown error\0" > + "Name has no usable address\0" > "Unrecognized address family or invalid length\0" > "Unrecognized socket type\0" > "Unrecognized service\0" > diff --git a/src/network/lookup_name.c b/src/network/lookup_name.c > index bec6ba22..37d481f9 100644 > --- a/src/network/lookup_name.c > +++ b/src/network/lookup_name.c > @@ -79,7 +79,7 @@ static int name_from_hosts(struct address buf[static MAXADDRS], char canon[stati > case 0: > continue; > default: > - badfam = EAI_NONAME; > + badfam = EAI_NODATA; > break; > } > > @@ -175,7 +175,7 @@ static int name_from_dns(struct address buf[static MAXADDRS], char canon[static > __dns_parse(abuf[i], alens[i], dns_parse_callback, &ctx); > > if (ctx.cnt) return ctx.cnt; > - return EAI_NONAME; > + return EAI_NODATA; > } > > static int name_from_dns_search(struct address buf[static MAXADDRS], char canon[static 256], const char *name, int family) Some details to work out: 1. getaddrinfo errors out with EAI_NONAME early when AI_ADDRCONFIG finds that the requested address family is not configured. The logic here probably needs to be changed to still perform a lookup but suppress the results if all requested families were precluded by AI_ADDRCONFIG. 2. gethostbyname* need to process EAI_NODATA and convert to (already existing) NO_DATA. 3. There was one other point where EAI_NONAME appeared in lookup_name.c but it was wrong and just fixed by 1e7fb12f77. Anything else? Rich