1115482 - [B2G][DNS] Allow to make DNS query without being blocked by implementation change of bionic in AOSP.

Status: RESOLVED DUPLICATE of bug 992772

(Firefox OS Graveyard :: RIL, defect)

Description

[Bevis Tseng[:bevis][:btseng](Exited)]

While analyzing bug 1114657 and bug 1058282, we realized that:
1. Started from JB[1] to KK[2] inside bionic of AOSP, 
2. For "default" network interfaces(Data or WiFi),
3. When making DNS query with unspecified address family(AF_UNSPEC),
4. Google made some change to check whether ipv4 and ipv6 has to be queried by
   checking whether UDP socket to 8.8.8.8 and 2000:: is able to be established 
   or not.
5. If no query to make for both ipv4/ipv6, NS_NOTFOUND is returned directly.
6. In currently gecko design, unless bug 992772 is fixed to specify correct 
   |iface| to bionic in KK[2] to skip these check, all "non-default" network 
   interfaces like MMS, SUPL, IMS and DUN are treated as "default" in bionic.
   Then, NS_NOTFOUND will be returned if WiFi/Data is Off.
   (No default route is available for 8.8.8.8 and 2000::.)
6. Moreover, in Lollipop [3], the condition of |(_using_default_dns(iface))| 
   before probing 8.8.8.8 & 2000:: was removed.
   We have to trace the entire networking implementation in Lollipop to figure 
   out if this change implies that 8.8.8.8 and 2000:: are always accessible for 
   all network interfaces.
   If yes, we need to figure out another solution to prevent this problem 
   happened in Lollipop.

Note: In gecko, AF_UNSPEC/AI_ADDRCONFIG are the default options for DNS query and 
      there is no entry point to specify this per request in the higher-level 
      modules like XMLHttpRequest when we'd like to make a HTTP request via a
      non-default network interface like MMS.

Hence, this bug is filed to ensure that we are able to do DNS query through specified network interface without being blocked by bionic implementation mentioned above, i.e., dependency to default routing or probing to 8.8.8.8, 
2000::.

[1] http://androidxref.com/4.3_r2.1/xref/bionic/libc/netbsd/net/getaddrinfo.c#1927
[2] http://androidxref.com/4.4.4_r1/xref/bionic/libc/netbsd/net/getaddrinfo.c#1932
[3] http://androidxref.com/5.0.0_r2/xref/bionic/libc/dns/net/getaddrinfo.c#1920

Comment 2

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Bevis Tseng ([e-mail]) from comment #0)
> 6. Moreover, in Lollipop [3], the condition of |(_using_default_dns(iface))| 
>    before probing 8.8.8.8 & 2000:: was removed.
>    We have to trace the entire networking implementation in Lollipop to
>    figure out if this change implies that 8.8.8.8 and 2000:: are always accessible
>    for all network interfaces.
>    If yes, we need to figure out another solution to prevent this problem 
>    happened in Lollipop.

Update what we have found so far:
1. In Lollipop, for making DNS query over non-default network interface, |netd| will always remove AI_ADDRCONFIG before querying it. [1]
2. |iface| is deprecated in Lollipop with |net-id| to identify different network.

Hence, similar to bug 992772, to prevent being blocked by |_have_ipv4()|, |_have_ipv6()| in [2] for DNS query over non-default network interface, we have to specify correct |net-id| to |android_getaddrinfofornet()|[3].

[1] http://androidxref.com/5.0.0_r2/xref/system/netd/server/DnsProxyListener.cpp#211
[2] http://androidxref.com/5.0.0_r2/xref/bionic/libc/dns/net/getaddrinfo.c#1920
[3] http://androidxref.com/5.0.0_r2/xref/bionic/libc/dns/net/getaddrinfo.c#592

Comment 3

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Bevis Tseng ([e-mail]) from comment #2)
> Update what we have found so far:
> 1. In Lollipop, for making DNS query over non-default network interface,
> |netd| will always remove AI_ADDRCONFIG before querying it. [1]
That means we won't fall into the tests of |_have_ipv4()|, |_have_ipv6()| with negative responses in [2].
[2] http://androidxref.com/5.0.0_r2/xref/bionic/libc/dns/net/getaddrinfo.c#1920

Comment 4

[Bevis Tseng[:bevis][:btseng](Exited)]

Mark as duplicated to bug 992772, according to the analyzed result in comment 2.