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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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

Closed by  Allan McRae (Allan)
Saturday, 30 October 2010, 09:33 GMT
Reason for closing:  Upstream
Comment by Allan McRae (Allan) - Saturday, 14 August 2010, 12:16 GMT
This is one of these great glibc bugs that will likely not get fixed in a hurry (or ever...). Upstream see their implementation as correct (which I suppose it technically is) and just because it breaks lots of things does not mean they should change it.

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.
Comment by Michele Scandale (skadotnet) - Saturday, 14 August 2010, 12:50 GMT
Could be the problem related to the router that I'm using right now? I know that there isn't ipv6 compiled on the linux box of the router, can this fact cause this behaviour? OpenDNS answers to the AAAA request, maybe the fact that ipv6 isn't present in the router implies that it can't answer to that request an so this may cause the delay. I don't know how these things works technically, so my question is: "Is this reasonable?". If it is I can try (never tried before, so quite dangerous for the router) to rebuild the firmware image with ipv6 enabled.

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.
Comment by Michele Scandale (skadotnet) - Sunday, 15 August 2010, 22:37 GMT
Seen that the problem isn't the fact that ipv6 is not enabled on the router, is the problem in glibc? What those dns request to produce that behaviour in glibc?
Comment by Jan de Groot (JGC) - Monday, 16 August 2010, 10:51 GMT
Can you try adding this to /etc/resolv.conf:
"options single-request-reopen"
Comment by Michele Scandale (skadotnet) - Monday, 16 August 2010, 13:14 GMT
It doesn't work, the delay is still present.
Comment by Michele Scandale (skadotnet) - Tuesday, 14 September 2010, 14:00 GMT
I've solved changing the dns-proxy daemon on the router firmware, there was dproxy-nexgen, I replaced it with dnsmasq that support AAAA requests and so now glibc is happy that receives all the answers.
Comment by Allan McRae (Allan) - Saturday, 30 October 2010, 09:32 GMT
I'm going to close this as "upstream" given you have worked around the issue.

Loading...