FS#20470 - [glibc] getaddrinfo inadmissible delay
Attached to Project:
Arch Linux
Opened by Michele Scandale (skadotnet) - Saturday, 14 August 2010, 09:14 GMT
Last edited by Allan McRae (Allan) - Saturday, 30 October 2010, 09:33 GMT
Opened by Michele Scandale (skadotnet) - Saturday, 14 August 2010, 09:14 GMT
Last edited by Allan McRae (Allan) - Saturday, 30 October 2010, 09:33 GMT
|
Details
I recently bought a new modem/router for my dsl connection,
and changing my network configuration from static-ip/dns to
dynamic, i've seen this problem: surfing the web the name
resolution cost a lot of time! I've tried to change the
nameserver int /etc/resolv.conf directly to OpenDNS (that
i've configured in my router) and no problem has been seen.
I thought that was a problem related to the router, but with
other OS this not happen. So after some googling I've found
that a possible solution was to disable ipv6 module, that
solved the problem with firefox, but not in example with
wget that still waste time on resolving name. I googled
again and I found this
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757, it's a bug report of ubuntu similar problem related to
getaddrinfo routine of glibc package, so I tried to trace
wget with ltrace and I found that the time wasting is on
getaddrinfo routine. With wireshark I've seen a strange
behaviour: there are sent 2 dns request, one of type A (ipv4
address) and the other of type AAAA (ipv6 address). The
second type request will never have an answer, but after a
millisecond arrives from the gateway the answer for the
first type request. After 5 seconds from the first request,
another couple of request (A and AAAA) is sent again with
the same transaction ids of the first couple, the answer
arrives again but is again "ignored", and again after 10
seconds from the first request, a couple of request is sent
and the answer received, waiting 5 seconds and the finally
the start of HTTP protocol.
I've attached 2 wireshark sessions: - direct-dns, is the recording while using directly in /etc/resolv.conf OpenDNS nameserver - router-dns, is the recording while using as nameserver the gateway that use OpenDNS nameserver Maybe there's something wrong in the way of interpreting that kind of response. |
This task depends upon
Until something gets done to fix this upstream, I can only suggest you continue using a good DNS server or the workaround in comments 288/290 of the bug you linked.
Thanks anyway.
EDIT: tried with ipv6 enabled on the router (rebuilt the kernel with support of ipv6 activated), no change :-(, it seems to be a "local" problem.
"options single-request-reopen"