Bug 13651 – resolver fails if result to first query fails but second succeeds

Bug 13651 - resolver fails if result to first query fails but second succeeds


Summary:	resolver fails if result to first query fails but second succeeds

Status:	NEW

Product:	glibc
Classification:	Unclassified
Component:	network
Version:	unspecified

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Not yet assigned to anyone

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2012-02-02 00:27 UTC by Aurelien Jarno
Modified:	2012-12-19 10:47 UTC (History)
CC List:	1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Patch to fix the issue (1.20 KB, patch) 2012-02-02 00:27 UTC, Aurelien Jarno	Details \| Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Aurelien Jarno 2012-02-02 00:27:36 UTC

Created attachment 6187 [details]
Patch to fix the issue

When using a nameserver which doesn't support IPv6, it might returns FORMERR or
NOTIMP, though it's not supposed to be the case according to the RFC. When this
corresponds to the first answer (which is usually the case as it's faster to
just return an error than doing a recursive query), resplen (that is the
returned value) ends up being 0 and resplen2 > 0. The tests in
__libc_res_nsearch() only look at resplen and totally ignore resplen2.

The attached patch fixes that by testing if resplen > 0 or resplen == 0 (that
is empty result, but no error) and resplen2 > 0.