This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug network/15726] getaddrinfo() returns incorrect status
- From: "kurt at roeckx dot be" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 28 Aug 2013 21:20:00 +0000
- Subject: [Bug network/15726] getaddrinfo() returns incorrect status
- Auto-submitted: auto-generated
- References: <bug-15726-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=15726
--- Comment #27 from Kurt Roeckx <kurt at roeckx dot be> ---
(In reply to Rich Felker from comment #26)
> I disagree with this:
>
> "In case there was a negative answer it's unclear what should be returned.
> Some implementations return EAI_FAIL, others EAI_NONAME."
>
> In the case of a negative answer, EAI_NONAME is the only correct answer. You
> have an answer: the name does not resolve. POSIX directly specifies this as:
There clearly is disagreement about what the behavior should be, which is why I
didn't say what should be returned. I can see arguments for both ways.
> [EAI_NONAME]
> The name does not resolve for the supplied parameters. [or]
> Neither nodename nor servname were supplied. At least one of these shall be
> supplied.
I can interpret the "for the supplied parameters" as meaning the AI_NUMERIC*
cases, since it seems the reason for the failure is is the parameters. And the
text above indicates in which cases EAI_NONAME should be returned.
But I can also interpret is as just not resolving, and that it's not a limiting
list of cases. There is also Stevens's implementation that returns EAI_NONAME
in this case.
EAI_FAIL on the other hand talks about a "non-recoverable error", which can be
just about anything.
> For instance (this one actually hit me
> recently due to misconfiguration in a resolv.conf file) the nameserver could
> give response code 5 (Refused) if it's authoritative-only and you're sending
> recursive requests to it, or if it's configured to be accessible only to
> certain client IP addresses. This condition should probably be ignored
> however if there are other nameservers to fall back to. As for the other
> response codes, most of them seem to be things that either should not
> happen, or that would warrant EAI_AGAIN rather than EAI_FAIL.
We should just not use that nameserver anymore (for the current lookup), and if
we find no nameservers that give us an answer it should result in "no answer" /
EAI_FAIL. But I'm not sure how detailed we should go with all those things.
--
You are receiving this mail because:
You are on the CC list for the bug.