Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
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
|
DetailsI 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
direct-dns.pcap
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"