Bug 448284
Summary: | firefox 10 sec delays trying DNS AAAA {ipv6} requests on dns server that makes no ipv6 response | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Timms <dtimms> | ||||||||||
Component: | firefox | Assignee: | Gecko Maintainer <gecko-bugs-nobody> | ||||||||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | low | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 9 | CC: | atkac, lemenkov, mcepl, walters | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i686 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2008-06-24 13:33:54 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
David Timms
2008-05-25 13:01:52 UTC
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. |