This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/13651] New: resolver fails if result to first query fails but second succeeds
- From: "aurelien at aurel32 dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 02 Feb 2012 00:27:36 +0000
- Subject: [Bug libc/13651] New: resolver fails if result to first query fails but second succeeds
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=13651
Bug #: 13651
Summary: resolver fails if result to first query fails but
second succeeds
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper.fsp@gmail.com
ReportedBy: aurelien@aurel32.net
Classification: Unclassified
Created attachment 6187
--> http://sourceware.org/bugzilla/attachment.cgi?id=6187
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.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.