DNS-over-TLS (RFC7858)

[spacekitteh]

RFC7858

From my limited understanding, Bionic appears to implement Android's DNS lookup mechanism. Thus it must be investigated if this is even possible without separating out the libresolv-ish parts from libc in order to link to a TLS lib.

Here seems to be the meat of the implementation.

Some items of interest:

• android_getaddrinfo_proxy for doing DNS lookup over a proxy
• Linux kernel module for DTLS

Related upstream issue/feature request

[thestinger]

It definitely shouldn't involve code in the kernel.

[thestinger]

It definitely shouldn't involve code in the kernel.

[spacekitteh]

Indeed, it is merely an example of a complete-ish implementation at a low level. Do the external deps use Bionic for their libc as well?

[spacekitteh]

Indeed, it is merely an example of a complete-ish implementation at a low level. Do the external deps use Bionic for their libc as well?

[thestinger]

Everything Android uses Bionic. If you wanted to bundle BoringSSL into Bionic you could.

[thestinger]

Everything Android uses Bionic. If you wanted to bundle BoringSSL into Bionic you could.

[spacekitteh]

As a workaround in the meantime, perhaps including a simple dns-over-tls-supporting resolver app and forward all requests to it might be acceptable?

[spacekitteh]

As a workaround in the meantime, perhaps including a simple dns-over-tls-supporting resolver app and forward all requests to it might be acceptable?

[thestinger]

It can likely just be done in netd because DNS requests are likely already proxied to netd from everywhere else by default and preventing apps from shooting themselves in the foot by going out of the way to change that isn't necessary.

[thestinger]

It can likely just be done in netd because DNS requests are likely already proxied to netd from everywhere else by default and preventing apps from shooting themselves in the foot by going out of the way to change that isn't necessary.

[stensonb]

fair warning: I know nothing about android development or the android ecosystem...

why not use dnscrypt-proxy, and a local dns cache?

[stensonb]

fair warning: I know nothing about android development or the android ecosystem...

why not use dnscrypt-proxy, and a local dns cache?

[spacekitteh]

Dnscrypt is only for authentication, not privacy.

…

On Wed, 4 Jan 2017, 14:27 Bryan Stenson, ***@***.***> wrote: fair warning: I know nothing about android development or the android ecosystem... why not use dnscrypt-proxy <https://dnscrypt.org/>, and a local dns cache? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#536 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB2crKoVU3OQXb_6k-mrToFJxh0uqrrJks5rOx-XgaJpZM4LQFUK> .

[spacekitteh]

Dnscrypt is only for authentication, not privacy.

…

On Wed, 4 Jan 2017, 14:27 Bryan Stenson, ***@***.***> wrote: fair warning: I know nothing about android development or the android ecosystem... why not use dnscrypt-proxy <https://dnscrypt.org/>, and a local dns cache? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#536 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB2crKoVU3OQXb_6k-mrToFJxh0uqrrJks5rOx-XgaJpZM4LQFUK> .

[thestinger]

They might be interested in this upstream which would be a way of getting it done, not sure. Since DNS queries are usually followed by connecting to the resolved IP, it won't hide much other than hosts with multiple / many hostnames and in terms of authentication DNS should be untrusted either way. Authentication might be more useful in terms of mitigating denial of service a compromised DNS server, by falling back to a different server if authentication fails, but it's a marginal benefit.

[thestinger]

They might be interested in this upstream which would be a way of getting it done, not sure. Since DNS queries are usually followed by connecting to the resolved IP, it won't hide much other than hosts with multiple / many hostnames and in terms of authentication DNS should be untrusted either way. Authentication might be more useful in terms of mitigating denial of service a compromised DNS server, by falling back to a different server if authentication fails, but it's a marginal benefit.

[spacekitteh]

It is important for anonymity, like when using VPNs and Tor, for example.

[spacekitteh]

It is important for anonymity, like when using VPNs and Tor, for example.

[thestinger]

The DNS should be going over the VPN / Tor already.

[thestinger]

The DNS should be going over the VPN / Tor already.

[spacekitteh]

True enough

[spacekitteh]

True enough

[thestinger]

This is being implemented upstream so we'll just wait for it. It's a very low priority for us since the IP addresses are still leaked and TLS SNI leaks the domain being requested so there's not much really being hidden.

[thestinger]

This is being implemented upstream so we'll just wait for it. It's a very low priority for us since the IP addresses are still leaked and TLS SNI leaks the domain being requested so there's not much really being hidden.

[thestinger]

https://android-review.googlesource.com/#/q/topic:dns-dev-opt+(status:open+OR+status:merged)

[thestinger]

https://android-review.googlesource.com/#/q/topic:dns-dev-opt+(status:open+OR+status:merged)