Repository navigation
Add support for Android's LinkProperties.getDnsServers() #12
Description
Android got an API to retrieve the DNS servers (of a particular link) with Android 5.0 (API 21): LinkProperties.getDnsServers().
MiniDNS should make use of that API if possible. This probably means splitting MiniDNS into multiple artifacts:
- minidns-core: the "pure Java", i.e. non Android API, core of MiniDNS
- minidns-android21: Using the Android API >= 21 to retrieve the DNS servers
- minidns-android: Using the currently approach to discover the DNS servers on Android
- minidns-java: Using Java API to determine the DNS servers (not sure if such a thing exists though)
Activity
enko commentedon Aug 25, 2015
Who can I bribe to fix this issue? This issue prevents me from connecting to my xmppd in the application conversations via an openvpn link which sets the dns, but conversations does not use the dns server of the vpn, it uses the dns server of the normal internet link. As all the traffic is routed is over the vpn the old dns server will be reached via the vpn link and the dns server silently drops the package which results in a timeout.
Flowdalic commentedon Aug 26, 2015
I'd be happy to address this. But this may be not trivial. We need to first merge @mar-v-in's DNSSEC work, as it makes some fundamental changes to MiniDNS. So this issue is blocked by #7. And before this can be merged it needs to get submitted and reviewed, which may take a while.
Furthermore I'm not sure (yet) how the API should look and behave exactly. For example: How would MiniDNS determine which link to use? This information probably needs to be provided by the library user.
So I wouldn't wait for this to happen. Isn't it possible to manually set the XMPP server IP (and port) in conversations to avoid the DNS lookup?
enko commentedon Aug 26, 2015
Its not so easy in the xmpp world. xmpp uses SRV-records to indicate which host is responsible for serving xmpp. Maybe @iNPUTmice can tune in and provide some insight, on how to solve my connectivity problems.
Flowdalic commentedon Aug 26, 2015
How does this prevent you from manually specifying the IP address (or even multiple IP/port pairs) of the XMPP server? I suggest you create an conversations issue requesting this feature (if it doesn't exists already). Since we are going slightly OT now, please remember to keep this issue clean from unrelated content.
rtreffer commentedon Aug 27, 2015
The DNS server should by private to the VPN network, and routed that way. I don't think accessing the DNS server would be a problem.
We could also use getDomains to retrieve the search domains and prefer the VPN-DNS for those domains.
We can't however determine if all the traffic should go to this VPN DNS. And from a conceptual POV I think it would make more sense as part of the resolver that @mar-v-in has written. (Special rules about which DNS server handles what) (That would be a lot like bind lookup zones or the way you can configure the Mac OS X resolver)
iNPUTmice commentedon Aug 27, 2015
well by default it could use the link that also provides the default route.
Will try to provide some POC code. Honestly I don't care if its Conversations or mininds discovering the DNS serves. I just thought that minidns might be a more centralized place as others will have the same problem in the future
rtreffer commentedon Aug 27, 2015
@iNPUTmice So basically getRoutes + a check for 0.0.0.0 and/or 2000::/8 in that case using this links DNS? Sounds reasonable. Should be easy for the DNS Server lookup method.
But I'm wondering if we should support the the search domains. VPNs usually push their primary domain as a search domain. So we could route it to that DNS if VPN search domain == suffix of requested domain. (Example: You work for corp.com, your internal network is inside.corp.com, you request xmpp.insinde.corp.com -> use the DNS of the VPN - this should work for most company VPNs). Such a logic should be part of a toplevel resolver IMHO.
iNPUTmice commentedon Aug 27, 2015
This would at least solves OPs problem - I think - as OP is using a personal VPN just for privacy reasons that routes all of OPs traffic. (And thus could not reach the default DNSs)
I haven't thought about how to handle the case were I route only part of network through the VPN
Flowdalic commentedon Aug 27, 2015
Yep, that's the hard part I meant when I asked how MiniDNS should determine to which link the query belongs too.
iNPUTmice commentedon Jun 21, 2017
This
AndroidUsingLinkPropertieslookup mechanism could act as a starting ground.Currently the preference regarding IPv4 addresses is hard coded because AbstractDnsClient doesn't make the IpSettings publicly readable.
I realize that IpSettings doesn't necessarily indicate how the DNS server itself should be queried however I had been using the IPv4 preference previously because $REASONS. (Some networks combined with some power saving features might make IPv6 servers unreachable)
Flowdalic commentedon Jun 30, 2017
@iNPUTmice Can you confirm that you additionally put https://github.com/siacs/Conversations/blob/4a2e222b34291c0657323ca8aa35f1f301139257/src/main/java/eu/siacs/conversations/utils/AndroidUsingLinkProperties.java under the license terms of MiniDNS:
This would allow me to include work based on your work into MiniDNS.
iNPUTmice commentedon Jun 30, 2017
yes
Flowdalic commentedon Sep 21, 2017
Fixed with 5d7fa26