Name resolving by DNS is too slow (more than 5 seconds)

NEW
Unassigned

Status

Firefox OS
GonkIntegration
--
major
4 years ago
4 years ago

People

(Reporter: Masashi Honma, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [perf-reviewed])

(Reporter)

Description

4 years ago
The Firefox OS name resolving is too slow on my environment.

I watched the wireshark log.

The Firefox OS sent "DNS Query" to local gateway (router).
But the gateway is not a DNS server and DNS proxy.
So the gateway doesn't responded to the DNS query.
Five seconds later, the Firefox OS sent "DNS Query" to DNS server and got response.

I have tested same thing on Ubuntu 13.04 on same environment.
Ubuntu 13.04 sent 3 DNS queries at one time.
1. to local gateway
2. to DNS1
3. to DNS2
Ofcourse Ubuntu 13.04 got DNS response less than 5 seconds (about 1 second).

Is it a bug ?

Gaia: 6ed5464af84f3c420b78259dff53f57a6f1be75e
Gecko: 8fdb69114734785065ce6c76ac36f4438b90c2e6
Hardware: KEON
Are you able to run the following marionette test python script on the target device to measure the actual DNS resolving time? I tried on my device and it resolved very quickly. The dns server I used is 8.8.8.8.

Thanks :)

---------------------------------------------------------------------------------
from marionette import Marionette
marionette = Marionette('localhost', 2828)
marionette.start_session()
marionette.set_context(marionette.CONTEXT_CHROME)

script = """
  let dnsService = Components.classes["@mozilla.org/network/dns-service;1"].
                     getService(Ci.nsIDNSService);
  
  const hostname = "http://www.mozilla.org";
  
  let ips = dnsService.resolve(hostname, Ci.nsIDNSService.RESOLVE_BYPASS_CACHE);
  while (ips.hasMore()) {
    dump("Resolved ip for " + hostname + " is " + ips.getNextAddrAsString());
  }
"""

marionette.execute_script(script)
-------------------------------------------------------------
(Reporter)

Comment 2

4 years ago
(In reply to Henry Chang [:henry] from comment #1)

> I tried on my device and it resolved very quickly.

My gateway does not have ability to respond to DNS query.
Did you test it with such a gateway ?
(Reporter)

Comment 3

4 years ago
(In reply to Henry Chang [:henry] from comment #1)

What is a purpose of running this script ?

Do you want to know where wastes the time ?
(Firefox OS framework or other thing)

I have already watched the wireshark log.
There were 5 seconds between first DNS Query and second DNS Query.
This is a time displayed on wireshark.
So Firefox OS framework doesn't waste time.
(In reply to Masashi Honma from comment #3)
> (In reply to Henry Chang [:henry] from comment #1)
> 
> What is a purpose of running this script ?
> 
> Do you want to know where wastes the time ?
> (Firefox OS framework or other thing)
> 
> I have already watched the wireshark log.
> There were 5 seconds between first DNS Query and second DNS Query.
> This is a time displayed on wireshark.
> So Firefox OS framework doesn't waste time.

Just want to make sure we use the same way to do the DNS query.

How did you do the DNS query? Typing certain URL in the browser?
Adb to the cell phone and 'ping' or 'busybox ping' certain server?
If you were typing URL in the browser, you were using the XPCOM "DNS Service"
to do the DNS query. 

Besides, my gateway also couldn't respond the DNS query.

Thanks.
(Reporter)

Comment 5

4 years ago
(In reply to Henry Chang [:henry] from comment #4)

> How did you do the DNS query? Typing certain URL in the browser?

I typed a string into browser search field. Then DNS query for "google.com" was sent.
(In reply to Masashi Honma from comment #5)
> (In reply to Henry Chang [:henry] from comment #4)
> 
> > How did you do the DNS query? Typing certain URL in the browser?
> 
> I typed a string into browser search field. Then DNS query for "google.com"
> was sent.

In fact, gecko will cache the queried DNS for a while. Could you elaborate the 
steps to reproduce and the wireshark log? Thanks
(Reporter)

Comment 7

4 years ago
(In reply to Henry Chang [:henry] from comment #6)
> In fact, gecko will cache the queried DNS for a while. Could you elaborate
> the steps to reproduce and the wireshark log? Thanks

Reproducing procedure is here.
1. make reset-gaia (This step is needed to remove history in browser.)
2. reboot KEON
3. boot browser application
4. boot wireshark
5. input a character 'a' to browser search area
6. wireshark can capture DNS query

And I can reproduce this by mozTCPSocket
Between time[1] and time[2] is more than 5 seconds.

    var time = [];
    time[0] = (new Date()).getTime();
    var tcpSocket = navigator.mozTCPSocket.open('www.google.com', 80, {
      binaryType: 'arraybuffer'
    });
    time[1] = (new Date()).getTime();
    tcpSocket.onopen = function() {
      time[2] = (new Date()).getTime();
    };
Jason, is this the right component for this bug? Who's the right person to look at this?
Component: General → Networking
Flags: needinfo?(jduell.mcbugs)
Product: Firefox OS → Core
Whiteboard: [perf-reviewed]
I'm putting this in networking::DNS, in case it's some sort of bug in our DNS code.  But I suspect it more likely some sort of config issue--we ultimately dispatch DNS requests to the OS, and the OS shouldn't be configured to send DNS requests to the gateway if the gateway isn't a DNS server.  
 
Masashi: Is this happening over wifi, or cellular service? Do we know if DHCP is being used, or is some other mechanism for setting the DNS server list being used?  

My guess is that somehow the DNS server list is {gateway, DNS server1, ...} but it shouldn't contain gateway.
Component: Networking → Networking: DNS
Flags: needinfo?(jduell.mcbugs) → needinfo?(masashi.honma)
FYI: I'm not sure how to get the list of DNS servers used by B2G.  The old-school way in linux is to read /etc/resolv.conf, but for DCHP, etc, it's stored elsewhere. I see a site claiming you should read /var/lib/dhcp/dhclient.leases (or other *.lease files in that directory).  Ubuntu says to use "nmcli dev list iface eth0" (substitute the active network interface for 'eth0').

It would be nice to see a list of the OS's DNS servers, just to sanity check my theory that we're getting bogus first entry (the gateway).  Then we can try to figure out if this is unique to Mashashi's config, or a widespread issue.
From this document http://androidxref.com/4.3_r2.1/xref/ndk/docs/system/libc/OVERVIEW.html#274
libc on android uses net.dns1, net.dns2, etc.
(Reporter)

Comment 12

4 years ago
(In reply to Jason Duell (:jduell) from comment #9)
> Is this happening over wifi, or cellular service?

Wifi.

> Do we know if DHCP is being used, or is some other mechanism for setting the DNS server
> list being used?

DHCP.

> My guess is that somehow the DNS server list is {gateway, DNS server1, ...}
> but it shouldn't contain gateway.

I logged in to B2G with "adb shell" and I could see DNS server lists.
----------------
root@android:/etc # getprop net.dns1
192.168.3.1
root@android:/etc # getprop net.dns2                                           
202.238.95.24
root@android:/etc # getprop net.dns3                                           

----------------

I watched the DHCP ACK frame from the gateway by wireshark.
The Domain Name Server Option field included 3 DNS servers.
1) 192.168.3.1 (gateway IP address)
2) 202.238.95.24
3) 202.238.95.26
Indeed the gateway sends his own IP address as a DNS server address even if it can not respond to DNS query.
So this name resolving problem occurs only with such a insane gateway.

We can close this bug as a gateway problem.
But can somebody shorten the DNS query retry duration ?
Or send 3 DHCP query as Ubuntu 13.04 ?
Flags: needinfo?(masashi.honma)
I assume the point of this is to test fallback behavior - not that you're really interested in getting your gateway to respond to DNS :)

This is an OS issue.. you can configure the timeout in gonk as "options timeout:N" (for N seconds) in resolv.conf when the nameservers get put into that file.

1 second is probably too short for a mobile device at the tail.
Component: Networking: DNS → GonkIntegration
Product: Core → Firefox OS
You need to log in before you can comment on or make changes to this bug.