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: firefoxAssignee: Gecko Maintainer <gecko-bugs-nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: 9CC: 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 Flags
wireshark packet trace - looking up www.ford.com.au
none
pcap for below command.
none
pcap for below command:
none
pcap for below command A: none

Description David Timms 2008-05-25 13:01:52 UTC
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.

Comment 1 David Timms 2008-05-25 13:27:51 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.

Comment 2 David Timms 2008-05-25 22:16:41 UTC
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.

Comment 3 Adam Tkac 2008-05-26 14:46:49 UTC
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

Comment 4 Matěj Cepl 2008-06-23 22:01:49 UTC
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.

Comment 5 David Timms 2008-06-24 08:43:59 UTC
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

Comment 6 David Timms 2008-06-24 09:06:54 UTC
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

Comment 7 David Timms 2008-06-24 09:17:18 UTC
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.

Comment 8 David Timms 2008-06-24 09:31:14 UTC
(In reply to comment #7)
These are with the current firefox release:
firefox-3.0-1.fc9.i386
xulrunner-1.9-1.fc9.i386

Comment 9 Adam Tkac 2008-06-24 11:08:59 UTC
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

Comment 10 David Timms 2008-06-24 12:13:25 UTC
(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}.

Comment 11 Adam Tkac 2008-06-24 13:33:54 UTC
(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.