This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/15726] getaddrinfo() returns incorrect status


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]