Re: getaddrinfo error for existing host without requested address family
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 26 Oct 2022 19:38:01 UTC
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* resolve, > > > but has no AAAA record, and it is the same error message as for a name > > > that truly does not exist. The problem comes from the set of error > > > codes that getaddrinfo() returns in these two cases. The problem did > > > not exist with gethostbyname(), which has separate error codes for the > > > two (although gethostbyname did not have provision for IPv6, it handled > > > 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 supported */ > > > #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 without > > > an address for the requested address family. Also, that is the error > > > 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 specifying 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 family. > > > 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_* errors > > > from <nsswitch.h> internally and then translates. But it will benefit > > > 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_ADDRFAMILY. > - 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 message. > The has the main disadvantage that we have several NLS translations. Also, > 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 seems > reasonable for this case. > Any comments or votes? I am inclined to use EAI_ADDRFAMILY as originally > 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