Bug 704347

Summary: Extremely slow dns resolution on ipv4 network
Product: [Fedora] Fedora Reporter: lauplesser
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: dcbw, jklimes, tore
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 15:59:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description lauplesser 2011-05-12 21:13:23 UTC
Description of problem:

Even if you disable the ipv6 connectivity (ipv6 set to "ignore") in the NetworkManager, the os is still trying to do AAAA dns query over ipv4. The result is simple : each dns resolution takes 10+ seconds ...

Version-Release number of selected component (if applicable):

NetworkManager 0.8.999-1.fc15

How reproducible:
100%

Steps to Reproduce:
1.connect to a ipv4 network and dns server only
2.set the ipv6 settings in the NetworkManager to ignore ipv6
  
Actual results:

If an application try to use the internet, each connection attempt will takes 10+ seconds. Tested with the gnome packet manager, rythmbox, vlc. You can also see it in firefox but there is an option in the about:config page named "network.dns.disableIPv6" that can solve the issue (but only for firefox).

I diagnosticed the issue with wireshark. You can clearly see three burst of dns query separated from each other by several seconds. Each burst is constituted by an A query, then a valid ipv4 answer from the server, then an AAAA query and no answer from the server.
The weirdest part is that even if it got a valid ipv4 answer the first time, because of the lack of the answer for the AAAA query, it will try another 2 burst of query before falling back on the ipv4 answer.

Expected results:

Just fast dns resolution.

Additional info:

Comment 1 Jirka Klimes 2011-05-13 13:01:16 UTC
This is probably caused by buggy DNS servers that didn't respond to AAAA request.
Mind that resolvers still can make (and really make) AAAA requests because every interface has at least link-local IPv6 address (even without external connectivity). That's how getaddrinfo(), used by resolvers, works.

So I suggest you used different DNS servers, e.g. http://en.wikipedia.org/wiki/OpenDNS of google public servers: 8.8.8.8, 8.8.4.4

Useful links:
* http://tools.ietf.org/html/rfc4074
  Common Misbehavior Against DNS Queries for IPv6 Addresses
* https://bugzilla.redhat.com/show_bug.cgi?id=505105
* https://bugzilla.redhat.com/show_bug.cgi?id=459756

Try:
$ time dig @<your_DNS_IP> AAAA <name_you_want_to_resolve>
$ time dig @8.8.8.8 AAAA <name_you_want_to_resolve>

Comment 2 lauplesser 2011-05-13 20:10:13 UTC
I understand that the problem comes from the dns server that should at least answer an error code. But I live in a country (Belgium) without any public ipv6 network so there is no reasons at all to try an AAAA query on the belgian dns server. I think if you specify “ignore ipv6“, there is no reasons of doing AAAA queries.
Fedora is the first os were I meet this issue and believe me, I tried a lot of linux and bsd distributions.
So I consider this as a bug, or at least as a lack of features.

But while trying your solutions, I got another problem :
So I switched my router dns configurations and I started fedora : now I don't have any dns resolutions at all. So I changed back the parameters of my router but still nothing. So I restarted the computer and the router and again nothing. What's odd is that other devices connected on the very same network and interface work with no problems ...

Comment 3 lauplesser 2011-05-13 20:13:56 UTC
Some precisions :
The local network is working fine, there is just no dns query send on the network.

Comment 4 Tore Anderson 2011-07-08 16:18:57 UTC
This is fixable by 1) applying the patch in https://bugzilla.redhat.com/show_bug.cgi?id=697149 , and 2) ensuring applications are setting the AI_ADDRCONFIG flag when calling getaddrinfo(). (Firefox already does.)

Tore

Comment 5 Fedora End Of Life 2012-08-07 15:59:07 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping