Description of problem: When ever a go to a new site {or one that firefox decides it needs to check the dns for again}, there is a huge delay while it works out that ipv6 aint an options Version-Release number of selected component (if applicable): firefox-3.0-0.60.beta5.fc9.i386 How reproducible: Two machines within my house. One is a fresh install, the other an fresh install, that uses pre-existing /home/ user account. Steps to Reproduce: 1. f9 fresh install 2. firefox 3. url=www.ford.com.au Actual results: for about 10 seconds, nothing visible happens, then the page starts to load, if the page links to off site media/ad/statistics then the interval until the page is complete is rather unbearable. Expected results: With a fast internet connection, working dns on a siemens adsl router, I expect {and a third machine running F8 has} page load times of < 0.5 seconds for basic pages. Additional info: dig www.ford.com.au, www.news.com.au {and others} Query time=45msec, 14 msec. time dig =0.09s , 0.06s Wireshark capture shows that firefox is going awol waiting for non-existent ipv6 dns query responses, and then something else. workaround: In previous times I have added to modprobe.conf: install ipv6 /bin/true, which seriously speeds up internet access, by immediately beginning the page load, rather than waiting 10 seconds. I thought I had another bug about this issue years ago, but can't seem to find it.
Created attachment 306615 [details] wireshark packet trace - looking up www.ford.com.au 0.0>4.9 sec: AAAA dns request of primary dns server 4.9>5.0 sec: arp request to check is dns server=router ip alive 5.0> 5.01s : AAAA dns request of secondary dns server [isp's] gets a response 5.01>5.04s : A dns request of secondary dns server 5.04s> : connect and begin getting page.
Perhaps this effect is the alternate universe effect of bug 323261 ? or https://bugzilla.mozilla.org/show_bug.cgi?id=425194 or https://bugzilla.mozilla.org/show_bug.cgi?id=417242 By the way, the adsl modem/router [siemens speedstream 4200] was the default router supplied by my country's largest ISP for ADSL2 service a few years ago. The router is under some load from uploading the fedora 9 iso image to max 8 peers; while this is the case other machines, and the problematic machines themselves can dig an address and have the response within 0.1 secs.
From network traces it seems for me that your primary server doesn't handles AAAA queries well. If you run "dig <name>" dig asks only for A records, not for AAAA. Would it be possible attach output from "dig @<your_primary_dns> www.ford.com.au AAAA", please? (of course when firefox delays, not when firefox works well) Thanks
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Created attachment 310116 [details] pcap for below command. sorry guys, didn't have access to my work notebook when your query came through, and forgot all about it: $ time dig @203.0.178.198 www.ford.com.au AAAA ; <<>> DiG 9.5.0rc1 <<>> @203.0.178.198 www.ford.com.au AAAA ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached real 0m15.009s user 0m0.003s sys 0m0.006s
Created attachment 310120 [details] pcap for below command: $ time dig @192.168.16.1 www.ford.com.au AAAA ; <<>> DiG 9.5.0rc1 <<>> @192.168.16.1 www.ford.com.au AAAA ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached real 0m15.009s user 0m0.005s sys 0m0.007s
Created attachment 310121 [details] pcap for below command A: $ time dig @192.168.16.1 www.ford.com.au A ; <<>> DiG 9.5.0rc1 <<>> @192.168.16.1 www.ford.com.au A ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42557 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ford.com.au. IN A ;; ANSWER SECTION: www.ford.com.au. 2573 IN CNAME www.ford.com.au.edgesuite.net. www.ford.com.au.edgesuite.net. 21584 IN CNAME a1643.b.akamai.net. a1643.b.akamai.net. 4 IN A 203.206.129.18 a1643.b.akamai.net. 4 IN A 203.206.129.9 ;; Query time: 41 msec ;; SERVER: 192.168.16.1#53(192.168.16.1) ;; WHEN: Tue Jun 24 19:06:56 2008 ;; MSG SIZE rcvd: 137 real 0m0.060s user 0m0.002s sys 0m0.006s === Note: attach/comment 5 was a foo.
(In reply to comment #7) These are with the current firefox release: firefox-3.0-1.fc9.i386 xulrunner-1.9-1.fc9.i386
As I expected your DNS server is broken. It returns nothing to AAAA query. Correct behavior is return NOERROR response with nothing in answer section (for example my server returns this for AAAA google.com record): $ dig google.com AAAA ; <<>> DiG 9.5.0rc1 <<>> google.com AAAA ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51279 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN AAAA ;; AUTHORITY SECTION: google.com. 300 IN SOA ns1.google.com. dns-admin.google.com. 2008062400 7200 1800 1209600 300 ;; Query time: 38 msec ;; SERVER: 10.34.255.7#53(10.34.255.7) ;; WHEN: Tue Jun 24 11:51:42 2008 ;; MSG SIZE rcvd: 78 It seems you are using router as caching DNS. One solution will be use your ISP nameservers as default nameservers (configure dhcp on your router appropriately) which should handle AAAA queries well. Other solution is disable IPv6 completely on your machines and if firefox using getaddrinfo(3) function correctly it should not ask for AAAA records. Would it be possible check if this works, please? Thanks
(In reply to comment #9) > As I expected your DNS server is broken. It returns nothing to AAAA query. > Correct behavior is return NOERROR response with nothing in answer section What percentage of home based router/firewalls get this correct do you think ? > It seems you are using router as caching DNS. Correct. > One solution will be use your ISP > nameservers as default nameservers (configure dhcp on your router appropriately) > which should handle AAAA queries well. Yes. I had to use my internal one to get the results in the previous attachments. Using the external ISPs DNS server "works around" this problem. > Other solution is disable IPv6 completely on your machines and if firefox using > getaddrinfo(3) function correctly it should not ask for AAAA records. Would it > be possible check if this works, please? Thanks Once I posted this issue, I used the old workaround of setting /etc/modprobe.conf to [install ipv6 /bin/true]. This has been working since I posted this bug. I'm sure this is not the only {home} router that has this issue. I wouldn't have bothered to detail a bug if I didn't think it was important enough to get fixed {do we want to repeatedly spend our time providing users with manual workarounds, or do we want to try to push a permanent solution upstream that just works for everyone's benefit ?}. What would it take to convince the firefox guys that instead of the end user having to workaround this issue, that firefox instead makes two parallel DNS request {1x AAAA, 1xA} at the same time ? If there is no response from the second request within {say} double the time it took to get the first response, then use the IP type of the response received. If both are received then use ipv6. This would then fit with the "need to be ready for ipv6 notion", yet no cripple an otherwise high speed connection {by default}.
(In reply to comment #10) > What percentage of home based router/firewalls get this correct do you think ? Not sure. But if it is broken it should be fixed. Writting workaround in every program is not permanent solution and only hides original problem. > Yes. I had to use my internal one to get the results in the previous > attachments. Using the external ISPs DNS server "works around" this problem. As expected because your ISP provider honor RFCs. > Once I posted this issue, I used the old workaround of setting > /etc/modprobe.conf to [install ipv6 /bin/true]. This has been working since I > posted this bug. > > I'm sure this is not the only {home} router that has this issue. I wouldn't have > bothered to detail a bug if I didn't think it was important enough to get fixed > {do we want to repeatedly spend our time providing users with manual > workarounds, or do we want to try to push a permanent solution upstream that > just works for everyone's benefit ?}. > > What would it take to convince the firefox guys that instead of the end user > having to workaround this issue, that firefox instead makes two parallel DNS > request {1x AAAA, 1xA} at the same time ? > > If there is no response from the second request within {say} double the time it > took to get the first response, then use the IP type of the response received. > If both are received then use ipv6. This would then fit with the "need to be > ready for ipv6 notion", yet no cripple an otherwise high speed connection {by > default}. In theory it is nice but in real word it will not work. How you can say that AAAA record doesn't exist when server doesn't respond? It is impossible. Main problem is that we should honor standards instead "simply get it works". Address selection problem is written in RFC 3484. If you think that it is not correct you can propose update, then IETF will look onto it and after that RFC will be updated then we can do things "better". Problem is in router, no doubt. It should be fixed because it simply doesn't honor standards. firefox uses glibc getaddrinfo function. You can tune it in /etc/gai.conf file. You can try add something like label ::1/128 1 label ::/0 2 label 2002::/16 3 label ::/96 4 label ::ffff:0:0/96 0 precedence ::1/128 50 precedence ::/0 40 precedence 2002::/16 30 precedence ::/96 20 precedence ::ffff:0:0/96 100 to that file. It should prefer IPv4 addresses but I'm affraid it's not permanent and "right" solution. If it also doesn't work (waiting for AAAA record even if IPv4 is preffered) please reopen this bug against glibc component. Make sure that I don't want cause problems and leave things broken. But it's impossible keep Internet infrastructure working when some pieces doesn't honor standards.