Bug 141113 - bind resolver tries ipv6 AAAA resolv.conf search domains before ipv4 A = slow
bind resolver tries ipv6 AAAA resolv.conf search domains before ipv4 A = slow
Status: CLOSED DUPLICATE of bug 140528
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2004-11-29 08:43 EST by Trevor Cordes
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:07:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Trevor Cordes 2004-11-29 08:43:09 EST
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

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

Now I do:
tcpdump -i lo

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):

How reproducible:

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

Actual Results:  5 to 15 second delay before the client responds.

Expected Results:  0 to 2 second delay before the client responds.

Additional info:
Comment 1 Jason Vas Dias 2004-11-29 09:08:45 EST

*** This bug has been marked as a duplicate of 140528 ***
Comment 2 Red Hat Bugzilla 2006-02-21 14:07:19 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.