<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Continuing on from the "boot ordering and resolvconf" thread;<br>
cc:ed to Helmut in case this gets filtered again; bcc:ed to<br>
<a class="moz-txt-link-abbreviated" href="mailto:683061@bugs.debian.org">683061@bugs.debian.org</a> since this is relevant for how that<br>
issue is addressed...<br>
<br>
Executive summary: The getaddrinfo() returns different values<br>
depending on the OS and on nsswitch.conf settings, making it<br>
very difficult to use getaddrinfo() return values to deciding how<br>
to handle an error.<br>
<br>
Here are the results of further experiments with getaddrinfo().<br>
I am using the attached x.c program. It tries to look up the<br>
valid domain name '<a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>' and an invalid name <br>
four times:<br>
* once with empty /etc/resolv.conf (in which case the resolver tries
127.0.0.1:53)<br>
* once with /etc/resolv.conf pointing to a working nameserver on my
LAN<br>
* once with empty /etc/resolv.conf (again)<br>
* once with /etc/resolv.conf pointing to an IP address where there
is no working nameserver<br>
<br>
OS is Debian 7.0.<br>
<br>
================================<br>
# ./a.out<br>
Making resolv.conf empty<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -2, errno = 2<br>
Results of looking up a bogus name: status = -2, errno = 2<br>
Writing nameserver option to resolv.conf<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = 0, errno = 101<br>
Results of looking up a bogus name: status = -2, errno = 2<br>
Making resolv.conf empty<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -2, errno = 2<br>
Results of looking up a bogus name: status = -2, errno = 2<br>
Writing incorrect nameserver option to resolv.conf<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -2, errno = 2<br>
Results of looking up a bogus name: status = -2, errno = 2<br>
================================<br>
<br>
As I saw before, status is always -2 (EAI_NONAME). The manpage<br>
doesn't say that errno is significant in that case. (It is
significant<br>
when status is -11.)<br>
<br>
Helmut got different results. Is the difference between my machine<br>
and Helmut's machine attributable to some diff in nsswitch.conf,<br>
perhaps? I have:<br>
<br>
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4<br>
<br>
I tested next with<br>
<br>
hosts: dns<br>
<br>
and got different results.<br>
<br>
================================<br>
Making resolv.conf empty<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -2, errno = 111<br>
Results of looking up a bogus name: status = -2, errno = 111<br>
Writing nameserver option to resolv.conf<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = 0, errno = 101<br>
Results of looking up a bogus name: status = -2, errno = 101<br>
Making resolv.conf empty<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -2, errno = 111<br>
Results of looking up a bogus name: status = -2, errno = 111<br>
Writing incorrect nameserver option to resolv.conf<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -2, errno = 111<br>
Results of looking up a bogus name: status = -2, errno = 111<br>
================================<br>
<br>
Now errno for empty or incorrect resolv.conf is 111 (ECONNREFUSED
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
).<br>
And with correct resolv.conf and bogus domain name errno is 101<br>
(ENETUNREACH). That doesn't make too much sense but as I<br>
said I don't think we are supposed to pay attention to errno if<br>
status is -2.<br>
<br>
Next I ran the program on Ubuntu 13.04 with "hosts: dns".<br>
<br>
================================<br>
Making resolv.conf empty<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -11, errno = 111<br>
Results of looking up a bogus name: status = -11, errno = 111<br>
Writing nameserver option to resolv.conf<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = 0, errno = 101<br>
Results of looking up a bogus name: status = -2, errno = 101<br>
Making resolv.conf empty<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -11, errno = 111<br>
Results of looking up a bogus name: status = -11, errno = 111<br>
Writing incorrect nameserver option to resolv.conf<br>
Results of looking up <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>: status = -11, errno = 110<br>
Results of looking up a bogus name: status = -11, errno = 110<br>
================================<br>
<br>
This is different in two ways. First the status is -11 (EAI_SYSTEM)<br>
instead of -2 (EAI_NONAME) when no nameserver can be reached.<br>
Second, there is now a difference between the empty-resolv.conf<br>
case and the resolv.conf-with-bogus-address case. In the latter<br>
case errno is 110 (ETIMEDOUT) instead of 111 (ECONNREFUSED).<br>
This is better.<br>
<br>
Debian 7.0 has libc6 version 2.13-37.<br>
Ubuntu 13.04 has libc6 version 2.17-0ubuntu5.<br>
<br>
What's behind all this? [google, google...] I see that in<br>
November 2012 a change was made upstream<br>
<br>
<a class="moz-txt-link-freetext" href="http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8">http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8</a><br>
<br>
in response to a complaint that the wrong status was returned<br>
in the case of an internal error (out-of-fds).<br>
<br>
<a class="moz-txt-link-freetext" href="http://sourceware.org/bugzilla/show_bug.cgi?id=14719">http://sourceware.org/bugzilla/show_bug.cgi?id=14719</a><br>
<br>
This is possibly the reason that I get status -11 instead of<br>
-2 on Ubuntu.<br>
<br>
But the result of the change was that getaddrinfo() returned<br>
EAI_SYSTEM in too many cases.<br>
<br>
<a href="http://sourceware.org/bugzilla/show_bug.cgi?id=15339">http://sourceware.org/bugzilla/show_bug.cgi?id=15339</a><br>
<br>
This has recently (May 2013) been fixed<br>
<br>
<a class="moz-txt-link-freetext" href="http://sourceware.org/bugzilla/show_bug.cgi?id=15635">http://sourceware.org/bugzilla/show_bug.cgi?id=15635</a><br>
<a class="moz-txt-link-freetext" href="http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188">http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188</a><br>
<br>
such that (IIUC) now getaddrinfo() should return different<br>
status/errno combinations for internal errors, network errors<br>
and name resolution failures. I haven't tested the upstream<br>
code yet.<br>
<br>
I don't get the impression that the handling of return values<br>
by the various eglibc layers has been well thought out and<br>
documented; the developers seem to be making changes ad-hoc.<br>
<br>
In any case, because of all these differences and changes we<br>
won't have a good, stable getaddrinfo() interface to program<br>
against until Jessie. In the meantime a program that needs to<br>
distinguish between different causes for a name resolution<br>
failure will have to do more than just check the status and<br>
errno from getaddinfo().<br>
-- <br>
Thomas<br>
</body>
</html>