Re: getaddrinfo error for existing host without requested address family

From: Mike Karels <mike_at_karels.net>
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