Re: getaddrinfo error for existing host without requested address family
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 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 , 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 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
Re: getaddrinfo error for existing host without requested address family
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 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 , 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 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.
Mike
Re: getaddrinfo error for existing host without requested address family
Mike, Just commenting to clarify what seems to be unclear about some RFC's. Rod > 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 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 , 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. RFC2553bis-02 is an old version of a draft that went to -09, this draft existed from May 2000 to March 2003, when it was changed to RFC3493 and published. When looking at RFC versions and history please use the IETF datatracker to help one find history and latest versions: https://datatracker.ietf.org/doc/rfc3493/ https://datatracker.ietf.org/doc/rfc2553/ Says obsolete by rfc3493 https://datatracker.ietf.org/doc/rfc2553bis/ redirects to rfc3493 Sadly goggle often sends one to a html version of a rfc/draft when one searches there for it. The html version does have a link in the banner to the proper datatracker page though. Use of and reference to IETF drafts in comments of the FreeBSD code and implementing them is full of the perils that there is rarely anyone tracking the work and keeping things up to date as the draft evolves and we end up with stale comments, and even stale implementations. rfc3493 still does not define EAI_ADDRFAMILY, one would have to search the mailing list archives to find what the rational for its removal was. Sadly that this is not summarized in section 9 of rfc3493, it should of been. > > 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 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. > > Mike > > -- Rod Grimes rgri...@freebsd.org
Re: getaddrinfo error for existing host without requested address family
On 27 Sep 2022, at 17:41, Viktor Dukhovni wrote: > On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote: > >> The first error message is misleading, because the name *does* resolve, >> but has no record, and it is the same error message as for a name >> that truly does not exist. > > FWIW, the distinction between NODATA and NXDOMAIN is these days not > infrequently violated at the authoritative nameserver: > > https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00 > > So whether or not a name actually exists or just fails to have the > requested record type is at times not easily determined. :-( All getaddrinfo() can do is translate what the resolver receives: - If there is an NXDOMAIN error, we should report that the name does not resolve; - If there is no error but no record of the requested type in the answer, we should report that there is no address of the requested type. If the server always uses NXDOMAIN, we’ll report as indicated for that domain. In my test case, I control the server :). Mike > -- > Viktor.
Re: getaddrinfo error for existing host without requested address family
On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote: > The first error message is misleading, because the name *does* resolve, > but has no record, and it is the same error message as for a name > that truly does not exist. FWIW, the distinction between NODATA and NXDOMAIN is these days not infrequently violated at the authoritative nameserver: https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00 So whether or not a name actually exists or just fails to have the requested record type is at times not easily determined. :-( -- Viktor.
Re: getaddrinfo error for existing host without requested address family
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 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 , 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 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.
getaddrinfo error for existing host without requested address family
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 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 , 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 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. Mike
