From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: Every since upgrading to FC3 (from FC2) the web has been extremely slow. It took me forever to track down the problem, but I'm sure this is it: The gist of the problem is the (new?) bind in FC3 tries to resolve a lookup using ipv6 first USING ALL resolv.conf search domains, and only then tries ipv4. Here's my resolv.conf search mydomain.com region.myisp.com myisp.com nameserver 127.0.0.1 Note: myisp.com seems to be very slow. To recreate this bug, try using a very slow far away (or even bogus?) nameserver for the last search domain. Now I do: tcpdump -i lo then: lynx http://redhat.com tcpdump (edited for brevity) shows me the resolver is trying: 07:33:28.886360 IP AAAA? www.redhat.com. (32) 07:33:28.887045 IP AAAA? www.redhat.com.mydomain.com. (46) 07:33:28.911696 IP AAAA? www.redhat.com.region.myisp.com. (49) 07:33:28.912407 IP AAAA? www.redhat.com.myisp.com. (46) 07:33:33.912145 IP AAAA? www.redhat.com.myisp.com. (46) 07:33:38.912194 IP A? www.redhat.com. (32) 07:33:38.912700 IP A www.redhat.com (102) Note how it takes 10 seconds to try all the ipv6 AAAA queries before trying the one A query that succeeds. I have tried turning off as much ipv6 as I can on my system (/etc/sysconfig/network: IPV6*=no). I am not using ipv6 and my isp is not using ipv6. I did find a usenet post saying passing -4 to named may help disable ipv6, but that option is only available in bind>=9.3 and FC3 is 9.2.x. I can prove the above is the cause of the 10+ second delays for lookups by removing the isp (or all) search domains. Then my lookups are very fast. Yet even then tcpdump shows me it is doing a lookup on the (at least) 2 AAAA records first. That means extra net (albeit lo) traffic for no reason. If someone uses search domains, especially ones outside their network, and a local caching name server, they will hit this problem and not know why everything is crawling. I think the resolver should try ipv4 FIRST, OR try ipv6 on the domain, then ipv4 on the domain and only then try the search domains. Version-Release number of selected component (if applicable): bind-9.2.4-2 How reproducible: Always Steps to Reproduce: 1. run a local caching name server 2. add some slow domains to your search line in /etc/resolv.conf 3. use a client (NOT host and dig) to hit a remote address causing a lookup Actual Results: 5 to 15 second delay before the client responds. Expected Results: 0 to 2 second delay before the client responds. Additional info:
*** This bug has been marked as a duplicate of 140528 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.