Date: Wed, 26 Oct 2022 14:38:01 -0500 From: Mike Karels <mike@karels.net> To: freebsd-net@freebsd.org Subject: Re: getaddrinfo error for existing host without requested address family Message-ID: <202210261938.29QJc14a023217@mail.karels.net> In-Reply-To: Your message of Mon, 17 Oct 2022 10:37:22 -0500.
next in thread | raw e-mail | index | archive | help
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 <netdb.h>, 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 <nsswitch.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202210261938.29QJc14a023217>