Re: getaddrinfo() return value chaos

[Helmut Grohne <helmut@subdivi.de>]

On Sun, Jul 07, 2013 at 02:30:33PM +0200, Thomas Hood wrote:
> Executive summary: The getaddrinfo() returns different values
> depending on the OS and on nsswitch.conf settings, making it
> very difficult to use getaddrinfo() return values to deciding how
> to handle an error.

Thanks for not giving up here. I attempted to reproduce your results
with your attached test program. Here are my results:

========================
Making resolv.conf empty
Results of looking up www.google.com: status = -11, errno = 111
Results of looking up a bogus name: status = -11, errno = 111
Writing nameserver option to resolv.conf
Results of looking up www.google.com: status = 0, errno = 101
Results of looking up a bogus name: status = -2, errno = 101
Making resolv.conf empty
Results of looking up www.google.com: status = -11, errno = 111
Results of looking up a bogus name: status = -11, errno = 111
Writing incorrect nameserver option to resolv.conf
Results of looking up www.google.com: status = -11, errno = 110
Results of looking up a bogus name: status = -11, errno = 110
========================

This is an almost-sid box with libc6 2.17-5. The results are consistent
with my earlier observations.

> Helmut got different results. Is the difference between my machine
> and Helmut's machine attributable to some diff in nsswitch.conf,
> perhaps?  I have:
> 
>     hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

My system above has another variant:

      hosts: files gw_name dns

> This is different in two ways. First the status is -11 (EAI_SYSTEM)
> instead of -2 (EAI_NONAME) when no nameserver can be reached.
> Second, there is now a difference between the empty-resolv.conf
> case and the resolv.conf-with-bogus-address case. In the latter
> case errno is 110 (ETIMEDOUT) instead of 111 (ECONNREFUSED).
> This is better.

Indeed. So maybe mdns is to blame here for part of the trouble? Can you
verify that really the last mdns4 entry makes up for the difference?

> I don't get the impression that the handling of return values
> by the various eglibc layers has been well thought out and
> documented; the developers seem to be making changes ad-hoc.

Thanks for the extensive research here. I concur with your observation.

> In any case, because of all these differences and changes we
> won't have a good, stable getaddrinfo() interface to program
> against until Jessie.  In the meantime a program that needs to
> distinguish between different causes for a name resolution
> failure will have to do more than just check the status and
> errno from getaddinfo().

In particular one of the more recent bugs set out to return EAI_NONAME
when the network is unavailable. This may be a condition where a lookup
needs to be retried though.

Helmut