This is a deeply reworked https://github.com/c-ares/c-ares/pull/112, though I have changed everything except maybe tests. It still lacks proper sorting (rfc and sortlist), but I hope to fix it later. Update: sorting as a separate function available in #239

Summary of changes:

• ares_addrinfo structure, with allocating function ares__malloc_addrinfo/ares__append_addrinfo, the latter one links new addrinfo to existing one
• ares_sockaddr union; ares_process.c modified to use that union too
• ares_getaddrinfo function, first resolves port than looks into hosts file and than performs AAAA and A lookups for AF_UNSPEC and/or A/AAAA lookups for AF_INET/AF_INET6. The resulting list is not sorted. Also there are no aliases in hostent sense as they are represented via separate linked addrinfo structures.
  • lookup_service function, uses getservbyname_r to get numeric name of the service
    • getservbyname_r function, copied from getservbyport_r
  • fake_addrinfo function, allocates addrinfo if we have an ip address in host field (same as fake_hostent)
  • next_lookup function, for file and dns lookups
    • ares__get_addrinfo function gets ares_addrinfo from file, it differs a bit from similar function in gethostbyname
• ~~ares_parse_a_reply/ares_parse_aaaa_reply both changed to parse into ares_addrinfo structure~~ changed back in favour of private ares__parse_a/ares__parse_aaaa
• new tests, though there are no ares_parse_a_reply/ares_parse_aaaa_reply tests with ares_getaddrinfo yet
• manuals for all the public functions
• clang format file to keep things in order, though tests style is different

Currently AF_UNSPEC is not well supported by ares. This Pull Request is a first attempt of an implementation of ares_getaddrinfo. Many details of the RFC described getaddrinfo are not implemented, however I think it's good enough for a starting point. It gets tested through:

[ RUN ] AddressFamilies/MockChannelTestAI.FamilyV6/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyV6/0 (1 ms) [ RUN ] AddressFamilies/MockChannelTestAI.FamilyV4/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyV4/0 (1 ms) [ RUN ] AddressFamilies/MockChannelTestAI.FamilyV4_MultipleAddresses/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyV4_MultipleAddresses/0 (1 ms) [ RUN ] AddressFamilies/MockChannelTestAI.FamilyUnspecified/0 [ OK ] AddressFamilies/MockChannelTestAI.FamilyUnspecified/0 (2 ms)

Based off original patch submitted by Brad Spencer [email protected] via https://c-ares.haxx.se/mail/c-ares-archive-2016-04/0000.shtml

The original patch relied on Windows Vista-specific functions, I've made slight tweaks to load those functions dynamically for compatibility with older systems.

Below is the original submission comments: 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.

Building c-ares 1.17.0 from tarball c-ares-1.17.0.tar.gz fails because cmake can't find the following files:

• c-ares-config.cmake.in
• libcares.pc.cmake

I tried to build (with Ninja as build tool) with the following cmake command:

cmake -GNinja -DCMAKE_BUILD_TYPE:STRING=Release -DCARES_SHARED:BOOL=ON -DCARES_STATIC:BOOL=ON

I have reproduced the issue both on Debian Linux as on Windows using MinGW-w64 GCC in MSYS2 shell.

This is the output:

CMake Error: File /home/brecht/_/c-ares-1.17.0/c-ares-config.cmake.in does not exist.
CMake Error at /usr/share/cmake-3.13/Modules/CMakePackageConfigHelpers.cmake:316 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:606 (CONFIGURE_PACKAGE_CONFIG_FILE)


CMake Error: File /home/brecht/_/c-ares-1.17.0/libcares.pc.cmake does not exist.
CMake Error at CMakeLists.txt:623 (CONFIGURE_FILE):
  CONFIGURE_FILE Problem configuring file


-- Configuring incomplete, errors occurred!

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:

1. The global DNS suffix search list.
2. The primary and connection specific DNS suffixes if the global is not available.

When invoking ares_gethostbyname for a forward DNS name-to-address lookup, there seems to be a leak from ares_strdup, as reported by the clang/LLVM address sanitizer:

Making check in examples
Making check in CFHost
make  CFHostExample
  CCLD     CFHostExample
/bin/bash ../../libtool --mode execute ./CFHostExample
Asynchronous lookups...
By name 'localhost' (Forward DNS)...
    Resolved names:
        0: localhost
    Resolved addresses:
        0: ::1
        1: 127.0.0.1

=================================================================
==1551143==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 10 byte(s) in 1 object(s) allocated from:
    #0 0x7fac81a14bc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fac81325487 in ares_strdup (/usr/local/lib/libcares.so.2+0x10487)

This was/is demonstrated against c-ares-1.18.1 using https://github.com/gerickson/opencfnetwork/blob/user/gerickson/github-issue-8-forward-dns-deadlock/third_party/CFNetwork/repo/Host/CFHost.c#L2770 along with the example application https://github.com/gerickson/opencfnetwork/blob/user/gerickson/github-issue-8-forward-dns-deadlock/examples/CFHost/CFHostExample.c.

This branch is a development of #232. Some major changes are support of search domains and combining of ares_parse_a/aaaa_reply into ares__parse_into_addrinfo, though I haven't touched the original functions yet. I had to introduce additional flag ARES_AI_NOSORT to disable connecting to mock addresses while sorting. My first idea was to use ares_socket_functions, but there is no "getsockname" mock, so flag seems a better variant. Struct ares_addrinfo extended to keep ai_ttl and ai_cname_ttl. The latest ares_getaddrinfo fixes are not actual anymore, because the code is removed.

socklen_t should not be used in code, instead ares_socklen_t should be used. New type of ares_ssize_t to mimic ares_socklen_t since ssize_t isn't available on all platforms, must like socklen_t, we need to define our own as it is now part of the public headers.

To integrate the C-ares library with seastar, we need to be able to control the way socket IO is performed, since

1.) We optionally use our own network stack (virtio/dpdk) 2.) We do asynchronous even more asynchronous.

This patch set adds a virtual socket function struct to c-ares, which can be attached to an individual channel using a setter function. The socket IO code is modified to use these bound functions if set (which in turn forgoes a lot of socket options etc, with the assumption that the provider deals with such matters.

The patch does not modify any source files, it only adds 3 new files (CMakelists.txt, ares_build.h.cmake, ares_config.h.cmake) which form the build system. I've tried to go through as much of the autotools tests and extracted what I thought was appropriate, though many of the tests aren't as in-depth in CMake as they are for autotools ... it is unclear why some of them exist at all, I'm guessing for legacy systems that CMake probably doesn't support anyhow.

Building the library, and examples (adig, ahost, acountry) plus installation should work across a large number of tested platforms. The tests have not yet been integrated.

When trying to compile on AIX, I see the following error:

In file included from /tmp/aix_softwares/cares-1.14.0/ares_parse_a_reply.c:34:
/usr/include/arpa/nameser_compat.h:244:3: error: conflicting types for 'HEADER'
 } HEADER;
   ^~~~~~
In file included from /usr/include/arpa/nameser.h:645,
                 from /tmp/aix_softwares/cares-1.14.0/ares_parse_a_reply.c:29:
/usr/include/arpa/onameser_compat.h:265:3: note: previous declaration of 'HEADER' was here
 } HEADER;
   ^~~~~~

To compile, I did the following:

cd /path/to/cmake/source
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local/cares ..

Any suggestions on how to solve the problem? I would be willing to send a PR for this, if suggestion is given. Problem seems to be that on AIX both these HEADER is defined in both .h files. Please let me know.

In ares_set_sortlist, it calls config_sortlist(..., sortstr) to parse the input str and initialize a sortlist configuration.

However, ares_set_sortlist has not any checks about the validity of the input str. It is very easy to create an arbitrary length stack overflow with the unchecked memcpy(ipbuf, str, q-str); and memcpy(ipbufpfx, str, q-str); statements in the config_sortlist call, which could potentially cause severe security impact in practical programs.

This commit add necessary check for ipbuf and ipbufpfx which avoid the potential stack overflows.

fixes #496

Signed-off-by: hopper-vul [email protected]

In ares_set_sortlist, it calls config_sortlist(..., sortstr) to parse the input str and initialize a sortlist configuration.

However, ares_set_sortlist has not any checks about the validity of the input str. It is very easy to create an arbitrary length stack overflow with the unchecked memcpy(ipbuf, str, q-str); and memcpy(ipbufpfx, str, q-str); statements in the config_sortlist call, which could potentially cause severe security impact in practical programs.

For example, the litter case could produce a stack overflow:

#include "ares.h"
#include<stdlib.h>
typedef int8_t  i8;
typedef int32_t i32;
int main() {
    struct ares_channeldata *v0 = NULL; // channel
    i32 v2 = ares_init(&v0); // $relative
    i8 v5[] = "111.111.111.111*shellcode*shellcode*shellcode*/"; // sortstr
    i32 v6 = ares_set_sortlist(v0, v5); // $target
}

As ares_set_sortlist is a public interface of a widely-used library, i think it is necessary to add some checks to forbid further severe security bugs.

The documentation says:

ARES_OPT_UDP_PORT unsigned short udp_port;
The port to use for queries over UDP, in network byte order. The default value is 53 (in network byte order), the standard name service port.

Yet, the code says:

  // NOTE: c-ares is assuming `options->udp_port` is in host byte order!
  if ((optmask & ARES_OPT_UDP_PORT) && channel->udp_port == -1)
    channel->udp_port = htons(options->udp_port);

Hi,

I'm using c-ares recently, I noticed that there are a heavy OS calls in find_src_addr function , Do we have any way to optimize these OS calls out ?

When building c-ares with CMake the following files are installed: /lib64/cmake/c-ares/c-ares-targets.cmake /lib64/cmake/c-ares/c-ares-targets-noconfig.cmake /lib64/cmake/c-ares/c-ares-config.cmake /lib64/cmake/c-ares/c-ares-config-version.cmake

These files allow consumers using CMake to find/import c-ares using find_package(c-ares).

However, when building c-ares using the autotools buildsystem these files are not installed, meaning consumers cannot find/import c-ares that way.

Some Linux distributions build c-ares using CMake while others build it using autotools. This produces inconsistent and surprising behavior for consumers of c-ares. Consumers should not need to know or care how a library was built in order to use it.