public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jik at kamens dot us" <sourceware-bugzilla@sourceware.org> 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 Date: Wed, 13 Jul 2011 04:24:00 -0000 [thread overview] Message-ID: <bug-12994-131@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2011-07-13 4:24 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-07-13 4:24 jik at kamens dot us [this message] 2011-07-13 4:24 ` [Bug libc/12994] " jik at kamens dot us 2011-07-13 4:25 ` jik at kamens dot us 2011-07-14 0:50 ` ppluzhnikov at google dot com 2011-07-16 5:33 ` nick.jones@network-box.com 2011-12-10 8:32 ` oliverml1 at oli1170 dot net 2012-02-21 2:17 ` [Bug network/12994] " jsm28 at gcc dot gnu.org 2012-11-02 1:22 ` jrnieder at gmail dot com 2012-11-03 17:01 ` karme at karme dot de 2012-11-04 10:49 ` karme at karme dot de 2012-11-04 10:53 ` karme at karme dot de 2012-11-06 11:49 ` karme at karme dot de 2012-11-06 13:22 ` law at redhat dot com 2012-11-07 17:33 ` karme at karme dot de 2012-11-27 12:02 ` karme at karme dot de 2012-11-27 16:52 ` law at redhat dot com 2012-12-16 15:55 ` psimerda at redhat dot com 2014-04-16 7:34 ` siddhesh at redhat dot com 2014-04-16 9:11 ` siddhesh at redhat dot com 2014-04-30 6:38 ` siddhesh at redhat dot com 2014-06-27 12:55 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-12994-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).