DNS transport not working on Android

[wngr]

#1927 changed the DNS transport to use the trust_dns_resolver crate rather than the system's libc functions. This means, the DNS resolution is completely in process now. The standard configuration tries to read /etc/resolv.conf to parse the host's DNS settings and use them.
This doesn't work on Android (see https://github.com/bluejekyll/trust-dns/issues/652). Supporting Android looks like a can of worms (termux/termux-packages#1174), which is probably why that issue is also stalled.

I think rust-libp2p should offer a fallback to use the system resolver via libc and bring back the old code -- what do you say?

[mxinden]

First off, rust-libp2p supporting Android would be neat! Mind sharing what you are up to?

The standard configuration tries to read /etc/resolv.conf to parse the host's DNS settings and use them.

Would using a custom ResolverConfig be an option for you?

[wngr]

Actyx has been running rust-libp2p in production for quite some time now on different hosts, namely Linux, Windows, and Android. We're providing a p2p platform for building and running resilient apps in factories.

Would using a custom ResolverConfig be an option for you?

No, as we want to rely on the system resolver (so gethostbyname et al), because the devices our software runs on are mostly administered by corporate IT, and they're usually a bit picky about their network setup ;-). On Linux that's fine, as the system dns config is picked up via /etc/resolv.conf (hopefully ..), but not Android..

[mxinden]

Puuh, this (termux/termux-packages#1174) indeed seems to be a can of worms.

I think rust-libp2p should offer a fallback to use the system resolver via libc and bring back the old code -- what do you say?

I am a bit afraid of introducing yet another option to libp2p-dns. That said, I think it is worth exploring to see how intrusive offering that fallback would be.

[wngr]

The naive thing would be to provide something similar to what was implemented before #1927 using std::net::ToSocketAddrs. A downside I see with that is that /dnsaddr resolution won't work with that. For our use case, this would be fine.

If it has to work with /dnsaddr multiaddrs, this might add quite a bit of complexity (probably needs to depend on libresolv?).

What's your take on that? Do you see other issues?

[thomaseizinger]

Can we just add a 2nd DNS transport?

It sounds like we don't need to support both modes at runtime so simply composing a different DNS transport would fix the issue, wouldn't it? In other words, have:

• TrustDnsResolverTransport
• SystemDnsResolverTransport or AndroidDnsResolverTransport if you want to do something Android specific.

[wngr]

Yeah, I think that's the basic idea. My question was about the functionality offered by SystemDnsResolverTransport.

[mxinden]

From what I know today, this would be my preference:

1. Fix trust-dns to work on Android, i.e. have from_system_conf load the correct configuration on Android.
2. Use trust-dns by default but allow switching to std::net::ToSocketAddrs at compile time, not supporting /dnsaddr in the latter case.
3. Use a third library (like libresolv) to support all of /dns4, dns6 and dnsaddr across all platforms.

[wngr]

We're going to work around this by passing in the nameservers during construction, as there's no way for dynamic nameserver changes with trust-dns anyway (which is kind of a bummer for rust-libp2p).

I guess this ticket could be closed then; maybe add the limitations of the dns transport to its README?

[mxinden]

as there's no way for dynamic nameserver changes with trust-dns anyway (which is kind of a bummer for rust-libp2p).

I was not aware of this.

maybe add the limitations of the dns transport to its README?

Would you mind creating a small pull request @wngr?

[wngr]

I was not aware of this.

See for example https://github.com/bluejekyll/trust-dns/issues/1016#issuecomment-583895735.

Would you mind creating a small pull request @wngr?

Sure I will do that, soon-ish :-)

[mxinden]

Would you mind creating a small pull request @wngr?

Sure I will do that, soon-ish :-)

Friendly ping @wngr :)