mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #652] The resolver doesn't work on Android #267
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#267
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fabricedesre on GitHub (Jan 8, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/652
Describe the bug
Name resolution doesn't work when using the resolver on Android targets.
To Reproduce
Compile any sample using trust-dns-resolve for Android.
Expected behavior
Name resolution should work.
System:
Version:
Crate: resolver
Version: 0.10.2
Additional context
Android builds end up in the unix path, but there is no /etc/resolv.conf on Android. We need an Android specific implementation reading system properties instead (quite similar to what is done with the windows registry).
I'm willing to contribute support if project owners agree.
@bluejekyll commented on GitHub (Jan 8, 2019):
This would be great, thanks!
Do you know of any automated testing environments we could use to validate that this support wouldn't be broken after it's added?
@fabricedesre commented on GitHub (Jan 8, 2019):
Unfortunately no apart from private, custom setups :(
@bluejekyll commented on GitHub (Jan 8, 2019):
I wonder if we could somehow use any of this to help at least check compilation? https://docs.travis-ci.com/user/languages/android/
@thomcc commented on GitHub (Jan 11, 2019):
You can also check compilation by installing an android target with rustup, and passing --target to cargo build.
@Dushistov commented on GitHub (Feb 12, 2019):
I catched this issue when I try to use trust-dns via reqwest on Android:
@wngr commented on GitHub (May 11, 2021):
I wonder what you would think of adding a custom implementation to Android to figure out the system resolver config. According to this Stackoverflow post the universal solution to this would be to parse the output of
getprop, which returns something like:You'd have those for all interfaces, so I was thinking of just constructing a set of all dns servers, and use that for the system resolver config on Android.
What do you think about this approach?
ref https://github.com/bluejekyll/trust-dns/issues/1099#issuecomment-631785263
@link2xt commented on GitHub (Mar 9, 2023):
https://stackoverflow.com/questions/3070144/how-do-you-get-the-current-dns-servers-for-android says
getpropis not working on some Androids.But trust-dns-resolver can use a ConnectivityManager via j4rs.
An example of j4rs usage for similar purposes: https://github.com/n0-computer/iroh/pull/825
@djc commented on GitHub (Mar 10, 2023):
I'm happy to review a well-argued PR for this. j4rs seems like a pretty ugly workaround, but if we don't know of any alternatives I guess that's what we'll want to do.
@link2xt commented on GitHub (Mar 10, 2023):
There are also native APIs in the Android NDK, but they require recent Android API, at least API level 29 in most cases: https://developer.android.com/ndk/reference/group/networking
@djc commented on GitHub (Mar 10, 2023):
Ideally we'd have both and switch depending on the API level, if it's not too much extra work?
@link2xt commented on GitHub (Mar 10, 2023):
Here is some documentation on how DNS resolver works in Android: https://source.android.com/docs/core/ota/modular-system/dns-resolver
It seems to be possible to learn how to use
/dev/socket/dnsproxyddirectly from Rust and skip Java and bionic libc dependencies.Related bionic code referred to in the documentation is at https://android.googlesource.com/platform/bionic/+/refs/heads/master/libc/dns/
netd code is at https://android.googlesource.com/platform/system/netd/
@link2xt commented on GitHub (Oct 26, 2023):
dnsproxydsupportsresolv_res_nsendwhich allows to send arbitrary DNS queries: https://android.googlesource.com/platform/packages/modules/DnsResolver/+/refs/heads/main/res_send.hImplementation of the client is here: https://android.googlesource.com/platform/packages/modules/DnsResolver/+/refs/heads/main/res_send.cpp
It is similar to classic res_send interface.
resnsend command implementation is here: https://android.googlesource.com/platform/packages/modules/DnsResolver/+/refs/heads/main/DnsProxyListener.cpp
Sending commands to
/dev/socket/dnsproxydis easy, e.g. from Termux I can run:and get some answer.
Commands are null-terminated, without null byte you will get
500 Command too large for bufferresponse:github.com/aosp-mirror/platform_system_core@268c408310/libsysutils/src/FrameworkListener.cpp (L66)The documentation for
dnsproxydis the source code it seems.resnsendcommand gets 4 arguments:resnsendcommand itself, netId (which can be 0 forNETID_UNSETas described in https://android.googlesource.com/platform/packages/modules/DnsResolver/+/refs/heads/main/include/netd_resolv/resolv.h), flags andmsg(base64-encoded query).@link2xt commented on GitHub (Oct 26, 2023):
So I used this Python script to generate DNS query with dnspython:
It prints
b'OTIBAAABAAAAAAAABmdpdGh1YgNjb20AAA8AAQ=='.Then in Termux I run:
and get a binary response:
So it seems to work, only need to be able to open an unix socket, base64-encode your request and parse the response back.
@djc commented on GitHub (Oct 27, 2023):
@link2xt I don't think we'd want to send DNS requests via the Android DNS stack -- the issue here (as I understand it) is that we need to find out the default DNS servers from the operating system. Once we have those, I think we'd want to do our own UDP/TCP/QUIC stuff.
@link2xt commented on GitHub (Oct 27, 2023):
This seem to require interacting with Java services now: https://stackoverflow.com/questions/3070144/how-do-you-get-the-current-dns-servers-for-android
You can use Java APIs from Rust using j4rs, I don't see other solutions in this case: https://github.com/n0-computer/iroh/pull/825
But at this point it is probably easier to close the issue and say that Android apps using this API should use Java methods to find DNS servers and provide them to the Rust code.
So for my purposes I can fallback to using
/dev/socket/dnsproxydifAsyncResolver::tokio_from_system_conf()does not work.@Millione commented on GitHub (Apr 1, 2025):
I'm wondering if there have been any updates regarding its resolution, if not, is there any workaround suggesting?
@djc commented on GitHub (Apr 1, 2025):
There has been no work on this as far as I've seen. But I think the workaround suggested in https://github.com/hickory-dns/hickory-dns/issues/652#issuecomment-1783178552 makes a lot of sense.