From nobody Wed Oct 26 19:38:01 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MyJxs5Pjyz4h3pR for ; Wed, 26 Oct 2022 19:38:09 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4MyJxr66R9z40lk for ; Wed, 26 Oct 2022 19:38:08 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 29QJc1bS023218 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 26 Oct 2022 14:38:01 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 29QJc14a023217; Wed, 26 Oct 2022 14:38:01 -0500 (CDT) (envelope-from mike) Message-Id: <202210261938.29QJc14a023217@mail.karels.net> To: freebsd-net@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: getaddrinfo error for existing host without requested address family In-reply-to: Your message of Mon, 17 Oct 2022 10:37:22 -0500. List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23215.1666813081.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Oct 2022 14:38:01 -0500 X-Rspamd-Queue-Id: 4MyJxr66R9z40lk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.70 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; DMARC_NA(0.00)[karels.net]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; HAS_REPLYTO(0.00)[mike@karels.net]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[mike]; ARC_NA(0.00)[]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net] X-ThisMailContainsUnwantedMimeParts: N On Oct 17, I wrote: > On Wed, 28 Sep 2022, Konstantin Belousov wrote: > > On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote: > > > I recently noticed the following behavior: > > > = > > > % ping6 redrock > > > ping6: Name does not resolve > > > % host redrock > > > redrock.karels.net has address 10.0.2.2 > > > redrock.karels.net mail is handled by 10 mail.karels.net. > > > % ping6 nonexistenthost > > > ping6: Name does not resolve > > > = > > > The first error message is misleading, because the name *does* resol= ve, > > > but has no AAAA record, and it is the same error message as for a na= me > > > that truly does not exist. The problem comes from the set of error > > > codes that getaddrinfo() returns in these two cases. The problem di= d > > > not exist with gethostbyname(), which has separate error codes for t= he > > > two (although gethostbyname did not have provision for IPv6, it hand= led > > > cases like domain names and mail domains without IPv4 addresses). > > > = > > > getaddrinfo() uses a richer set of error codes than gethostbyname(),= but > > > still misses this case. However, looking at , I see > > > = > > > #if 0 > > > /* Obsoleted on RFC 2553bis-02 */ > > > #define EAI_ADDRFAMILY 1 /* address family for hostname not support= ed */ > > > #endif > > > ... > > > #if 0 > > > /* Obsoleted on RFC 2553bis-02 */ > > > #define EAI_NODATA 7 /* no address associated with hostname */ > > > #endif > > > = > > > I don't know why these two were omitted from the update to RFC 2553,= but > > > the first seems to me to be the correct error for an existing name w= ithout > > > an address for the requested address family. Also, that is the erro= r > > > message produced by Linux (Ubuntu 22.04.1). > > > = > > > NetBSD and OpenBSD produce the second of these two errors for a host > > > without the requested address. But they also produce the same error > > > when a name does not exist. > > > = > > > RFC 2553bis-02 has timed out, and is replaced by RFC 3493, which is = also > > > missing EAI_ADDRFAMILY. These are informational RFCs, not specifyin= g an > > > Internet standard. > > > = > > > I propose re-enabling EAI_ADDRFAMILY and using it for the situation > > > where a name exists but does not have an address in the requested fa= mily. > > > This would make the error in the example less misleading, and would = behave > > > the same as Linux in this regard. The change to netdb.h is trivial,= but > > > getaddrinfo() needs a little more work because it uses the NS_* erro= rs > > > from internally and then translates. But it will benef= it > > > from greater accuracy in other cases as well (e.g. "out of memory" > > > rather than "Name does not resolve"). > > > = > > > Comments? I have a change in progress, but wanted to float the idea > > > before I finish it and put it into review. > > Perhaps look there > > https://www.openwall.com/lists/libc-coord/2022/09/27/1 > > You might want to participate in the thread, instead of me. > I participated in a short discussion on that list. The TL;DR: > - Linux/glibc (Ubuntu at least) uses EAI_NODATA ("No address associated > with hostname") when a name is valid but does not have the requested > address family. This is better than FreeBSD currently, as it is > distinguished from EAI_NONAME ("Name or service not known"). But it > implies that there is no address in any family. (I showed an example > from ping6 above, but it turns out to be atypical.) > - The author of the musl C library for Linux plans to use EAI_NODATA as > well, but with a different error message. > - Linux also uses EAI_ADDRFAMILY, but only when a numeric address is in = the > wrong family, e.g. telnet -6 127.0.0.1. > - POSIX, like the latest RFC, does not define EAI_NODATA or EAI_ADDRFAMI= LY. > - There were no other opinions expressed. > I see two choices for FreeBSD when there is no address in the requested > family. One is to use EAI_NODATA, probably using a modified error messa= ge. > The has the main disadvantage that we have several NLS translations. Al= so, > it is different than Linux. > The other choice is to use EAI_ADDRFAMILY ("Address family for hostname > not supported") as originally proposed. The existing error message seem= s > reasonable for this case. > Any comments or votes? I am inclined to use EAI_ADDRFAMILY as originall= y > proposed. I put up a review, https://reviews.freebsd.org/D37139, with these changes. The changes should be submitted as several commits, as indicated in the review. Mike