This is a port of RFC 6724 compliant sorting function from Android Bionic project:
e919b116d3/libc/netbsd/net/getaddrinfo.c
The latest version is essentially the same, except two additional parameters to test connection with (mark/uid):
https://android.googlesource.com/platform/bionic/+/master/libc/dns/net/getaddrinfo.c
Please note that even that version has some restrictions. It doesn't support some rules from RFC 6724:
Rule 3 (Avoid deprecated addresses)
Rule 4 (Prefer home addresses)
Rule 7 (Prefer native transport)
Submitted By: Andrew Selivanov (@ki11roy)
* using portable ares_inet_pton and updated includes in ares-test-mock-ai
* forgot to remove deleted ares-test-ai.cc in Makefile.inc
Fix By: Christian Ammer (@ChristianAmmer)
This PullRequest fixes a bug in the function add_to_addrinfo which task is to add new addrinfo items to the ai_next linked list. Also additional unit tests for testing ares_getaddrinfo will be added:
Additional mock server test classes (ares-test-mock-ai.cc):
MockTCPChannelTestAI
MockExtraOptsTestAI
MockNoCheckRespChannelTestAI
MockEDNSChannelTestAI
RotateMultiMockTestAI
NoRotateMultiMockTestAI
Additional live tests (ares-test-live-ai.cc):
LiveGetHostByNameV4
LiveGetHostByNameV6
LiveGetHostByNameV4AndV6
Fix By: Christian Ammer (@ChristianAmmer)
Initial implementation for ares_getaddrinfo(). It is NOT compliant with RFC6724, though
it is expected to come closer to conformance prior to the next release.
Features not supported include sorted addresses and honoring of service and hints
parameters.
Implementation by: Christian Ammer (@ChristianAmmer)
The LiveGetLocalhostByAddrV6 test expected to see "localhost" in the
result when doing an address-to-name lookup for ::1 but on my system
that resolves to "ip6-loopback" because of this stanza in /etc/hosts:
$ grep ^::1 /etc/hosts
::1 ip6-localhost ip6-loopback
Fix By: Ben Noordhuis (@bnoordhuis)
Bug: #85
Quoting RFC 7686:
Name Resolution APIs and Libraries (...) MUST either respond
to requests for .onion names by resolving them according to
[tor-rendezvous] or by responding with NXDOMAIN.
A legacy client may inadvertently attempt to resolve a .onion
name through the DNS. This causes a disclosure that the client
is attempting to use Tor to reach a specific service. Malicious
resolvers could be engineered to capture and record such leaks,
which might have very adverse consequences for the well-being
of the user.
Bug: #196
Fix By: Ben Noordhuis @bnoordhuis
Add resolvconf_path to end of struct ares_options with ARES_OPT_RESOLVCONF option
so on Unix-like systems a custom path can be specified. If no path is specified,
/etc/resolv.conf is used like normal.
Fix By: Sarat Addepalli @SirR4T
Fixes Bug: #220
Review By: Brad House @bradh352
For #164, I mentioned that it seemed like the IPv6 nameserver blacklist should apply to all OSes. In a mailing list post, @bradh352 agreed and suggested that I file a PR to make it so.
This moves the blacklist check from being Windows-specific to being a general feature of config_nameservers(), no matter the nameserver source. It also simplifies the ares_ipv6_server_blacklisted() implementation to not parse and re-parse the blacklisted IPv6 addresses from strings on every check. I think they're almost as easy to read as a sequence of hex bytes in an array initializer, and it's definitely less work on each trip through the code.
Fix By: Brad Spencer @b-spencer
PR: https://github.com/c-ares/c-ares/pull/193
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
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.)
Original Patch From Brad Spencer:
https://c-ares.haxx.se/mail/c-ares-archive-2016-04/0000.shtml
My modifications include:
* Dynamically find GetBestRoute2 since it is a Windows Vista+ symbol, and will fall back to prior behavior when not available.
* Prefer get_DNS_AdaptersAddresses as the modifications should alleviate the concerns which caused us to prefer get_DNS_NetworkParams
* Update AppVeyor to use MinGW-w64 instead of the legacy MinGW
* Fix compile error in test suite for Windows.
Original message from patch below:
From: Brad Spencer <bspencer@blackberry.com>
Date: Fri, 29 Apr 2016 14:26:23 -0300
On Windows, the c-ares DNS resolver tries first to get a full list of
DNS server addresses by enumerating the system's IPv4/v6 interfaces and
then getting the per-interface DNS server lists from those interfaces
and joining them together. The OS, at least in the way the c-ares
prefers to query them (which also may be the only or best way in some
environments), does not provide a unified list of DNS servers ordered
according to "current network conditions". Currently, c-ares will then
try to use them in whatever order the nested enumeration produces, which
may result in DNS requests being sent to servers on one interface
(hosting the current default route, for example) that are only intended
to be used via another interface (intended to be used when the first
interface is not available, for example). This, in turn, can lead to
spurious failures and timeouts simply because of the server address
order that resulted because of the enumeration process.
This patch makes the (safe?) assumption that there is no other better
rule to chose which interface's DNS server list should be prioritized.
After all, a DNS lookup isn't something "per network"; applications
don't look up "these DNS names on this interface and those DNS names on
that interface". There is a single resource pool of DNS servers and the
application should presume that any server will give it the "right"
answer. However, even if all DNS servers are assumed to give equally
useful responses, it is reasonable to expect that some DNS servers will
not accept requests on all interfaces. This patch avoids the problem by
sorting the DNS server addresses using the Windows IPv4/v6 routing tables.
For example, a request to DNS server C on interface 2 that is actually
sent over interface 1 (which may happen to have the default route) may
be rejected by or not delivered to DNS server C. So, better to use DNS
servers A and B associated with interface 1, at least as a first try.
By using the metric of the route to the DNS server itself as a proxy for
priority of the DNS server in the list, this patch is able to adapt
dynamically to changes in the interface list, the DNS server lists per
interface, which interfaces are active, the routing table, and so on,
while always picking a good "best" DNS server first.
In cases where any DNS server on any interface will do, this patch still
seems useful because it will prioritize a lower-metric route's (and thus
interface's) servers.
The added api requires both some typedefs not previously imported
into the test build + the test code did not fully deal with
socket differences on windows.
* Added test case macro to automatically run tests twice, once "normal",
once with virtual IO.
* Changed most "live" query tests to run in dual mode to verify
at least simple socket IO via virtual functions
* Added test case for settings/duping socket functions & callback data
Built tarballs are not including all of the files needed
to build the test suite because they are missing from the
<target>_SOURCES variable in Makefile.am.
Fix up a couple of problems with configuring whether c-ares rotates
between different name servers between requests.
Firstly, ares_save_options() returns (in *optmask) the value of
(channel->optmask & ARES_OPT_ROTATE), which doesn't necessarily
indicate whether the channel is or is not actually doing rotation.
This can be confusing/incorrect if:
- the channel was originally configured without ARES_OPT_ROTATE
(so it appears that the channel is not rotating)
- the /etc/resolv.conf file includes the 'rotate' option
(so the channel is actually performing rotation).
Secondly, it is not possible to reliably configure a channel
to not-rotate; leaving off ARES_OPT_ROTATE is not enough, since
a 'rotate' option in /etc/resolv.conf will turn it on again.
Therefore:
- add an ARES_OPT_NOROTATE optmask value to allow explicit
configuration of no-rotate behaviour
- in ares_save_options(), report the value of channel->rotate
as exactly one of (optmask & ARES_OPT_ROTATE) or
(optmask & ARES_OPT_NOROTATE).
In terms of back-compatibility:
- existing apps that set ARES_OPT_ROTATE will continue to rotate,
and to have ARES_OPT_ROTATE reported back from ares_save_options()
- existing apps that don't set ARES_OPT_ROTATE will continue to
use local config/defaults to decide whether to rotate, and will
now get ARES_OPT_ROTATE or ARES_OPT_NOROTATE reported back from
ares_save_options() rather than 0.
Commit 46bb820be3 ("ares_init_options: don't lose init failure")
changed init behaviour so that earlier errors in initialization
weren't lost. In particular, if the user passes in specific
options but they are not applied (e.g. because of an allocation
failure), that failure needs to be reported back to the user; this
also applies when duplicating a channel with ares_dup().
However, other initialization failures can be ignored and
overridden -- in particular, if init_by_resolv_conf() or
init_by_environment() fail, then falling back to default values
is OK.
So only preserve failures from the init_by_options() stage, not
from all initialization stages.
Fixes issue 60.
GoogleTest assumes that there is a null pointer in argv[argc],
so make it look like that. Without this change, tests run with
command-line arguments get memory errors under valgrind/ASAN.
When fuzzing with AFL, if the LLVM-based instrumentation is
used (via the afl-clang-fast wrapper), then it is possible to
have a single execution of the fuzzer program iterate multiple
times over the fuzzing entrypoint (similar to libFuzzer's normal
mode of execution) with different data. This is much (e.g. 10x)
faster.
Add code to support this, by checking whether __AFL_LOOP is
defined at compile-time.
Also, shift the code to effectively be C rather than C++.
No need to depend on the rest of the test code (ares-test.h) for
the fuzzer entrypoint; this makes the entrypoint slightly simpler
to build with LLVM's libFuzzer.
Also shift the code to effectively be C rather than C++
Andrew Selivanov
Christian Ammer
Ben Noordhuis
Sarat Addepalli
Brad Spencer
David Hotham
Brad House
Gregor Jasny
David Drysdale
David Drysdale
Anna Henningsen
Calle Wilund
Calle Wilund