Revert "Switch to local UDP DNS resolver"

[Mygod]

Reverts #2635

I am not sure why you would want to remove uds. Local port is accessible by any process on the device and is potentially a security risk. UDS is protected by the filesystem permissions while local port is not.

[zonyitoo]

The only reason is that common DNS libraries doesn't support resolving with UDS.

Why is that a security risk?

[madeye]

We already opened ports for local shadowsocks socks5 server and DNS resolver...

[zonyitoo]

sslocal itself still need to resolve remote servers' domain names.

The DNS relay in sslocal is like a DNS server, which simply redirects DNS queries to both configured local and remote servers.

In sslocal's point of view, it requires 2 set of DNS servers:

1. for resolving remote servers' domain names
2. for DNS relay

[Mygod]

We already opened ports for local shadowsocks socks5 server and DNS resolver...

This port gives untrusted processes direct access to underlying DNS port and therefore leaks the user's identity information (DNS provider) and possibly more. Technically, socks5 port should not be exposed either, but this is less problematic.

[zonyitoo]

How about this:

1. The UDP DNS resolver should be kept for sslocal to resolve remote servers' domain names
2. For DNS Relay, the local DNS could be provided by a UDS server.

[madeye]

IMO, in any way, we have to expose the local resolver from sslocal, for tun2socks.

leaks the user's identity information (DNS provider)

In fact, with the local DNS resolver enabled, do a DNS query from any app can lead to this kind of leaking...

[madeye]

For DNS Relay, the local DNS could be provided by a UDS server.

Yes, I think it's doable.

[Mygod]

1. The UDP DNS resolver should be kept for sslocal to resolve remote servers' domain names

What UDP DNS resolver?

IMO, in any way, we have to expose the local resolver from sslocal, for tun2socks.

leaks the user's identity information (DNS provider)

In fact, with the local DNS resolver enabled, do a DNS query from any app can lead to this kind of leaking...

Not necessarily if ACL is set up properly. Another security risk regarding this is that an app can probe two consecutive ports for DNS to test if the user is running Shadowsocks in this mode.

I don't understand why you decided to take the trouble to remove all the UDS code that is already there. What do you gain from this?

It is ok to expose sslocal acl resolver since it will be accessible via the tun interface anyway.

[madeye]

Some background here: current shadowsocks-android resolves the hostname of a shadowsocks server to IPs before generate the JSON config for sslocal.

I don't understand why you decided to take the trouble to remove all the UDS code that is already there. What do you gain from this?

@zonyitoo plans to support resolving hostname for shadowsocks remote server in sslocal. This change will help simplify his implementation in shadowsocks-rust.

The UDP DNS resolver should be kept for sslocal to resolve remote servers' domain names

Can we also use UDS to do the DNS resolving of shadowsocks server's hostname?

[zonyitoo]

Can we also use UDS to do the DNS resolving of shadowsocks server's hostname?

It was done in the past. But it will require a RPC call everytime when I want to connect to a remote server.

This was done by a DNS library (trust-dns), which implements lots of things that a DNS resolver should do, for example, caching with TTL, multi nameservers support, recursive resolving, ...

[madeye]

It was done in the past. But it will require a RPC call everytime when I want to connect to a remote server.

RPC calls are almost free for us. If I understand correctly, Android system should already cache the DNS queries, the real cost is just a local socket read/write.

I think we can revert back to the previous implementation, given @Mygod raised some security concerns here.

[zonyitoo]

Does getaddrinfo works in Android? If it works, then

1. since Android have already resolved servers' domain to IPs before starting sslocal, actually nothing could be done for sslocal's resolver.
2. sslocal uses getaddrinfo by default, which is also the default of tokio.

[madeye]

getaddrinfo works on Android.

But its queries will be sent to tun and intercepted by tun2socks then sent back to sslocal...

[madeye]

since Android have already resolved servers' domain to IPs before starting sslocal, actually nothing could be done for sslocal's resolver.

Yes, if we decide not to resolve server's hostname in sslocal, we can revert to the previous solution without any problem.

But its queries will be sent to tun and intercepted by tun2socks then sent back to sslocal...

Another possible trick is that we always bypass the ss-server's hostname to the local resolver. In that way we have something like this:

sslocal's getaddrinfo --(1)--> tun2socks --> sslocal's DNS relay --(2)--> ss-android's UDS based system resolver

1. resolve server's hostname
2. bypass to local resolver

[zonyitoo]

That would become similar to the redir.

Ok, I will add back support UDS of local-dns-addr.