From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29093 invoked by alias); 13 Jul 2011 04:24:18 -0000 Received: (qmail 29079 invoked by uid 22791); 13 Jul 2011 04:24:16 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jul 2011 04:24:03 +0000 From: "jik at kamens dot us" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12994] New: getaddrinfo fails if response records returned in wrong order and one of them is server failure X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jik at kamens dot us X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 13 Jul 2011 04:24:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-07/txt/msg00059.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12994 Summary: getaddrinfo fails if response records returned in wrong order and one of them is server failure Product: glibc Version: 2.14 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper.fsp@gmail.com ReportedBy: jik@kamens.us Created attachment 5848 --> http://sourceware.org/bugzilla/attachment.cgi?id=5848 tcpdump capture from getaddrinfo en.wikipedia.org A program calls getaddrinfo. Deep within the bowels of the resolver library, __libc_res_nquery in res_query.c creates two queries, an A query and an AAAA query. Deeper within the bowels of the resolver library, send_dg in res_send.c sends both queries and waits for responses. My name server sends the response to the *second* query *first*, and it's a server failure. I'm pretty sure that if the responses were sent in the reverse order, the problem would not occur. At this point things get all screwed up. I'm not sure whether the problem is in send_dg or _libc_res_nsend or _libc_res_nquery. I've spent hours poring over the code trying to figure out who is at fault. I can't, because this is some of the most poorly written code I've looked at in a very long time. It's completely incomprehensible and most of its "cleverness" is inadequately documented. Anyway, by the time status results bubble back up to getaddrinfo, the code has decided that it was unable to resolve the host name to an address, even though one of the two responses that came back from the DNS server had a valid A record in it. Test case? Run getaddrinfo on en.wikipedia.org immediately after restarting your name server. I'm using BIND 9.8.0-7.P4.fc15.x86_64; I don't know how universal this behavior is. I am attaching a wireshark dump from the virtual interface that captures both my loopback interface (on which my client is making its queries) and the queries my DNS server is making to try to satisfy the local queries. And here's what my test program (which I will also attach) prints as output: Wed Jul 13 00:14:18 2011: getaddrinfo: Name or service not known Note that if you run the exact same getaddrinfo call a second time immediately afterwards it works, because the previous successful query response, which is a CNAME, is cached and gets returned in response to both the A and AAAA queries. Since this bug causes DNS queries that should succeed to fail in a very user-visible way, I'm tempted to set it to critical, but I suppose since there's no permanent loss of data it isn't actually. I don't know, tough call. -- 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.