Some android systems like ARM64 may not have the __system_property_get
symbol in libc (but still have it in the public headers). Detect this
condition at build time. The __system_property_get method of retrieving
name servers is deprecated as of Oreo so should strictly be a fallback
mechanism anyhow.
As of Android 8 (Oreo) access to net.dns# has been removed (https://developer.android.com/about/versions/oreo/android-8.0-changes.html). The reasoning given is that it, "improves privacy on the platform". Currently c-ares uses this to get the list of DNS servers.
Now the only way to access the DNS server list is by using the Connectivity Manager though Java. This adds the necessary JNI code to use the Connectivity Manager and pull the DNS server list. The old way using __system_property_get with net.dns# remains for compatibilty.
Using the Connectivity Manager requires the ACCESS_NETWORK_STATE permission to be set on the app. Existing applications most likely are not setting this and keeping the previous method as a fallback will at the very least ensure those apps don't break on older versions of Android. They will need to add this permission for Android 8 compatibility.
Included in the patch are two initalization functions which are required. The JVM must be registered as well as the Connectivity Manager itself. There is no way to get the Connectivity Manager except though Java. Either being passed down to C directly or by passing in an Android Context which can be used to get the Connectivity Manager. Examples are provided in the documentation.
When compiling c-ares with a build system that defines UNICODE,
bad versions of WinAPI functions are used causing failures or even
crashes. When windows.h is included in MBCS mode (like in the default
build system), the ..A versions are the same as using the one without
any suffix.
When `ares_cancel()` was invoked, `ares_gethostbyaddr()`
queries would fail with `ENOTFOUND` instead of `ECANCELLED`.
It seems appropriate to treat `ares_cancel()` like `ares_destroy()`,
but I would appreciate review of the correctness of this change.
Ref: https://github.com/nodejs/node/issues/14814Closes#138
qsort is not stable, in order to make it stable we need to record
the original index and add it as a secondary sort value when the
metrics are equal to prevent using DNS servers that may not work
at all as reported by some users.
9478908a49 introduced a length check
for records parsed by `ares_parse_naptr_reply()`. However, that
function is designed to parse replies which also contain non-NAPTR
records; for A records, the `rr_len > 7` check will fail as there
are only 4 bytes of payload.
In particular, parsing ANY replies for NAPTR records was broken
by that patch.
Fix that by moving the check into the case in which it is already
known that the record is a NAPTR record.
The TESTS target runs fuzzcheck.sh so make sure it is included
in the distributed tarball.
(The test itself will be pointless when run on a distribution, because
the fuzzing corpus directories are not shipped, but at least this
means that `make -C test test` should work.)
ares_process.c uses htonl, which needs <arpa/inet.h> included.
ares_getnameinfo.c uses a dynamically selected format string for
sprintf, which -Wformat-literal doesn't like. Usually one would use
inttypes.h and a format string "%" PRIu32, but C99 is too new for some
supported platforms.
This change solves issue #53.
Support for suffix search lists was already built in for Linux. The search list could be set via set_search. With this change the suffix search list from Windows is read from the registry and then set into the ares configuration via set_search. There are two sources for the search list:
The global DNS suffix search list.
The primary and connection specific DNS suffixes if the global is not available.
Contributed by @ChristianAmmer