c-ares / c-ares Goto Github PK

View Code? Open in Web Editor NEW

1.8K 82.0 588.0 7.59 MB

A C library for asynchronous DNS requests

Home Page: https://c-ares.org/

License: Other

C 88.31% Shell 0.21% Awk 0.07% Perl 0.20% Batchfile 0.03% CMake 3.84% Makefile 0.44% M4 6.85% NASL 0.04%

dns resolver dns-queries c async library

c-ares's Introduction

Overview

c-ares is a modern DNS (stub) resolver library, written in C. It provides interfaces for asynchronous queries while trying to abstract the intricacies of the underlying DNS protocol. It was originally intended for applications which need to perform DNS queries without blocking, or need to perform multiple DNS queries in parallel.

One of the goals of c-ares is to be a better DNS resolver than is provided by your system, regardless of which system you use. We recommend using the c-ares library in all network applications even if the initial goal of asynchronous resolution is not necessary to your application.

c-ares will build with any C89 compiler and is MIT licensed, which makes it suitable for both free and commercial software. c-ares runs on Linux, FreeBSD, OpenBSD, MacOS, Solaris, AIX, Windows, Android, iOS and many more operating systems.

c-ares has a strong focus on security, implementing safe parsers and data builders used throughout the code, thus avoiding many of the common pitfalls of other C libraries. Through automated testing with our extensive testing framework, c-ares is constantly validated with a range of static and dynamic analyzers, as well as being constantly fuzzed by OSS Fuzz.

While c-ares has been around for over 20 years, it has been actively maintained both in regards to the latest DNS RFCs as well as updated to follow the latest best practices in regards to C coding standards.

Code

The full source code and revision history is available in our GitHub repository. Our signed releases are available in the release archives.

See the INSTALL.md file for build information.

Communication

Issues and Feature Requests should be reported to our GitHub Issues page.

Discussions around c-ares and its use, are held on GitHub Discussions or the Mailing List. Mailing List archive here. Please, do not mail volunteers privately about c-ares.

Security vulnerabilities are treated according to our Security Procedure, please email c-ares-security at haxx.se if you suspect one.

Release keys

Primary GPG keys for c-ares Releasers (some Releasers sign with subkeys):

Daniel Stenberg <[email protected]> 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2
Brad House <[email protected]> DA7D64E4C82C6294CB73A20E22E3D13B5411B7CA

To import the full set of trusted release keys (including subkeys possibly used to sign releases):

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2 # Daniel Stenberg
gpg --keyserver hkps://keys.openpgp.org --recv-keys DA7D64E4C82C6294CB73A20E22E3D13B5411B7CA     # Brad House

Verifying signatures

For each release c-ares-X.Y.Z.tar.gz there is a corresponding c-ares-X.Y.Z.tar.gz.asc file which contains the detached signature for the release.

After fetching all of the possible valid signing keys and loading into your keychain as per the prior section, you can simply run the command below on the downloaded package and detached signature:

% gpg -v --verify c-ares-1.29.0.tar.gz.asc c-ares-1.29.0.tar.gz
gpg: enabled compatibility flags:
gpg: Signature made Fri May 24 02:50:38 2024 EDT
gpg:                using RSA key 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2
gpg: using pgp trust model
gpg: Good signature from "Daniel Stenberg <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 27ED EAF2 2F3A BCEB 50DB  9A12 5CC9 08FD B71E 12C2
gpg: binary signature, digest algorithm SHA512, key algorithm rsa2048

c-ares's People

Contributors

Stargazers

Watchers

Forkers

acmorrow greearb fanweixiao ppentchev tommie denik davidsansome irca coapp-packages azmfaridee deiiji kamedakyosuke dougkwan saghul etrun phonehold auxten thecount psaab inkymail keithws imoldman distrotech ouzhiyin pombredanne shileiyu tessel fredericgermain xuejianhui hocktj nmav nicolasnoble urielm micbarme azukiapp ajit100 gjasny koolhazz zerothree evelinad magictour tux-mind swayer tipih howaichun jbriggs-zvelo ezhangle harveyliufly emotional-engineering externpro anthonykirby dybekm g-p-s chrdwhdhxtszpzclljxk davidgfnet amesianx gongfupanada bitbouncer songliwei2014 michaeltalyansky dimbleby daviddrysdale flashbuckets zhangjinde noscripter p-push marcschier andersbakken agwa-forks indutny avikivity jqk6 private-forks nordsturm roguelazer zs-2014 disigma-network wolftronics-sbc garik- zyh329 yarshure dawsongzhao cute ht101996 xixiang230 zyuhu disigma-base iyefeng yodamaster qbit elcallio jinjiacun123 coslibs emaxerrno davidfoxhu tianjizhang stephen-sorley rcoscali scylladb reflejo

c-ares's Issues

Windows: Slow resolution due to querying of non-existing autoconf IPv6 servers

Affected

c-ares 0.13.0 w/ system DNS server list
Windows 7 (other Windows versions not tested, but potentially affected as well)

Problem

c-ares regressed in lookup time from a few milliseconds to >10s.

Pesky IPv6 DNS Servers (or: The cause)

Starting with #81 (or rather 1.13.0) I reliably and always observe massive delays from c-ares (via https://github.com/aria2/aria2/) running on Windows 7 when letting c-ares pick the name servers itself by querying the Windows configuration.

I tried looking into it, and c-ares now picks up 3 additional IPv6 DNS server addresses:

fec0:0:0:ffff::1
fec0:0:0:ffff::2
fec0:0:0:ffff::3

Those are site-local addresses that get autoconfigured in Windows for IPv6 whenever a NIC has no DHCP or static configured DNS servers, but IPv6 connectivity in theory. It seems it's Microsoft's attempt trying to implement https://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 (which they also authored)

So where are these coming from exactly?
Adding some printfs to get_DNS_AdaptersAddresses shows those DNS servers are configured for the "Loopback Pseudo-Interface 1" and "VirtualBox Host-Only Network" interfaces and picked up by c-ares from there.

It gets worse... c-ares "detects" a metric of -1 for all DNS servers incl. the non-functioning ones, and qsortreliably sorts the bad ones first in my configuration, causing c-ares to first query three servers on sitelocal hosts that do not even exist, resulting in multi-second delays of up to 14 seconds in my tests. The final dns server string c-ares generates for me is:
fec0:0:0:ffff::1,fec0:0:0:ffff::2,fec0:0:0:ffff::3,127.0.0.1

Remedies

Do not even consider the loopback interface, e.g. by amending the check for not-up interfaces to also skip loopbacks.

    if (ipaaEntry->OperStatus != IfOperStatusUp ||
        ipaaEntry->IfType == IF_TYPE_SOFTWARE_LOOPBACK)
        continue;

Addressing virtual interfaces such as "VirtualBox Host-Only Network" is a bit harder, tho
- Ignore all interfaces without a GatewayAddress?
- Explicitly blacklist those three IPv6 addresses?
Or revert to the old behavior of "GetNetworkParams first"...

cc author and committer of #81 @bradh352 @bagder

CFLAGS error

Hey guys,

I am not proficient with building from source, but unfortunately I have to since there is no package in Solus repos.

I am getting this:

/c-ares-1.11.0 # ./configure
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... yes
checking whether to enable debug build options... no
checking whether to enable compiler optimizer... not specified (assuming yes)
checking whether to enable strict compiler warnings... no
checking whether to enable compiler warnings as errors... no
checking whether to enable curl debug memory tracking... no
checking whether to enable hiding of library internal symbols... yes
checking whether to expose internal static functions for testing... no
checking for path separator... :
checking for sed... /usr/bin/sed
checking for grep... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ar... /usr/bin/ar
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking whether to build with code coverage support... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
configure: using CFLAGS: -mtune=generic -march=x86-64 -ftree-vectorize -g2 -O2 -pipe -fPIC -Wformat -Wformat-security -fno-omit-frame-pointer -fstack-protector-strong --param ssp-buffer-size=4 -fexceptions -D_FORTIFY_SOURCE=2 -feliminate-unused-debug-types -Wno-error -Wp,-D_REENTRANT
configure: CFLAGS error: CFLAGS may only be used to specify C compiler flags, not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=2
configure: error: Can not continue. Fix errors mentioned immediately above this line.
`

I am not sure if this is an issue from my side or yours. Would appreciate any feedback.

Addendum: Running on Solus 1.2. C-ares version 1.11.0.

Suggest adding WSAStartup/WSACleanup into c-ares library init/cleanup procedure on Windows

Recently, trying to use c-ares on Windows with no lucks (#155). After doing some research, it turns to out be the reason that winsock isn't initialized with WSAStartup() in advance, therefore c-ares functions don't work properly on Windows.

As a new user of c-ares, it is quite frustrating to run such simple code and only to find it doesn't works on Windows (though it works on linux). It is not explicitly mentioned in the document that WSASetup() should be called to initialize winsock before using c-ares functions. I just pretend this kind of setup would be taken care in the function ares_library_setup(), but it goes wrong, and takes me some times to look into the source codes and figure out what goes wrong.

Rather than letting users to initialize winsock on their own, it would be great if c-ares can take the responsibility to initialize winsock in ares_library_init() (through WSAStartup()) and clean it up in ares_library_clelanup() (throught WSACleanup()). As those are of platform dependent codes, by wrapping those into c-ares library init/cleanup would definitely increase protability across platforms.

If there are any good reasons for c-ares not to take the responsibility of setting/cleaning up winsock, it will also helps to remind users in the document, that winsock should be manually started up before using any c-ares functions, and be manually cleaned up afterwards.

p.s. There've been discussions about this winsock init/deinit topic in mailing list back to the year 2005, but it seem to be with no conclusion. reference: c-ares on windows - error 11

c-ares doesn't use dns suffix in the system.

windows OS

Open the Advanced TCP/IP settings dialog.
Append the DNS suffixes
Use App/c-ares1.10 connect to the web server name without the DNS suffix.

Result:
Failed to connect to the web server.
Have to use FQDN to connect to the web server.

ares_init.c, Line 1609

static int init_by_defaults(ares_channel channel)
{
…
// Need to Add code to find the suffix!

if (channel->ndomains == -1) {
/* Derive a default domain search list from the kernel hostname,
* or set it to empty if the hostname isn't helpful.
*/

ifndef HAVE_GETHOSTNAME

channel->ndomains = 0; /* default to none */

else

Configuring build on Linux does not fill pkg-config version

Hi,

c-ares/libcares.pc.in

Line 15 in b4f1ff7

Version: @VERSION@

The version is not filled when I configure the build. Maybe I am missing something but it was working on a previous version.

Best Regards,
Roland

cmake macro CARES_TYPE_EXISTS and -Werror

Users of c-ares that use cmake add_subdirectory have to be careful to not call add_subdirectory(c-ares) after adding common compile flags -Werror.

The compile test used by the macro doesn't use its test variable, so it throws -Wunused-variable.

This results in c-ares not detecting things like struct timeval.

Cross-compilation for MIPS fails under -Werror

After configuring a MIPS cross-compilation on a Debian x64 host with the following options

CC=/opt/rt-n56u/toolchain-mipsel/toolchain-3.4.x/bin/mipsel-linux-uclibc-gcc ./configure --host=mips-linux-gnu --enable-warnings --enable-werror

the build process fails with the following messages:

make  all-recursive
make[1]: Entering directory '/opt/c-ares-git'
make[2]: Entering directory '/opt/c-ares-git'
  CC       libcares_la-ares__close_sockets.lo
  CC       libcares_la-ares__get_hostent.lo
  CC       libcares_la-ares__read_line.lo
  CC       libcares_la-ares__timeval.lo
  CC       libcares_la-ares_cancel.lo
  CC       libcares_la-ares_data.lo
  CC       libcares_la-ares_destroy.lo
  CC       libcares_la-ares_expand_name.lo
  CC       libcares_la-ares_expand_string.lo
  CC       libcares_la-ares_fds.lo
  CC       libcares_la-ares_free_hostent.lo
  CC       libcares_la-ares_free_string.lo
  CC       libcares_la-ares_getenv.lo
  CC       libcares_la-ares_gethostbyaddr.lo
  CC       libcares_la-ares_gethostbyname.lo
  CC       libcares_la-ares_getnameinfo.lo
cc1: warnings being treated as errors
ares_getnameinfo.c: In function 'ares_getnameinfo':
ares_getnameinfo.c:95: error: cast increases required alignment of target type
ares_getnameinfo.c:101: error: cast increases required alignment of target type
ares_getnameinfo.c: In function 'lookup_service':
ares_getnameinfo.c:336: error: conversion to 'short unsigned int' from 'unsigned int' may alter its value
ares_getnameinfo.c:336: error: conversion to 'short unsigned int' from 'unsigned int' may alter its value
Makefile:1172: recipe for target 'libcares_la-ares_getnameinfo.lo' failed
make[2]: *** [libcares_la-ares_getnameinfo.lo] Error 1
make[2]: Leaving directory '/opt/c-ares-git'
Makefile:1671: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/opt/c-ares-git'
Makefile:851: recipe for target 'all' failed

Building v1.12 from source writes incorrect version number in libcares.pc

This was first reported here:
nghttp2/nghttp2#771

When building v1.12 from source, the /usr/local/lib/pkgconfig/libcares.pc file then contains the following:

#***************************************************************************
# Project        ___       __ _ _ __ ___  ___
#               / __|____ / _` | '__/ _ \/ __|
#              | (_|_____| (_| | | |  __/\__ \
#               \___|     \__,_|_|  \___||___/
#
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: c-ares
URL: http://daniel.haxx.se/projects/c-ares/
Description: asynchronous DNS lookup library
Version: -
Requires:
Requires.private:
Cflags: -I${includedir}
Libs: -L${libdir} -lcares
Libs.private:

I am not sure about the semantics of this file but it was the cause for nghttp2 not building from source:

checking for LIBCARES... no
configure: Requested 'libcares >= 1.7.5' but version of c-ares is -

(see the aforementioned issue for details)

When I manually changed the version number in /usr/local/lib/pkgconfig/libcares.pc, I could then build nghttp2 from source.

ares_set_servers - Assertion failed: ares__is_list_empty

change_servers.txt

This crash has been plaguing Node.js for a while. It happens when calling ares_set_servers with another query in progress. The original issue is nodejs/node#894 and @emotional-engineering also submitted a patch on the mailing list in April. I've also attached this patch here.

Here's the message before the crash:

Assertion failed: (ares__is_list_empty(&server->queries_to_server)), function ares__destroy_servers_state, file ../deps/cares/src/ares_destroy.c, line 102.

cc: @indutny

Live tests assume /etc/hosts (or equivalent) contains localhost

Extracted from issue #81 as a separate issue; quoting from there:

recent versions of Windows don't have an entry for localhost in the hosts file at all, so I think this is expected to fail on Windows for the file tests. Also, I'm not sure if all DNS servers will answer localhost with ::1 or 127.0.0.1 when queried. I think this test case itself might just be bad and not an actual c-ares failure (unless of course it would be desirable to internally provide localhost resolution if not in the hosts file).

Heres the output of vtest:

[ RUN ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/0
HostCallback({ARES_ECONNREFUSED {'' aliases=[] addrs=[]}})
[ OK ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/0 (0 ms)
[ RUN ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/1
HostCallback({ARES_SUCCESS {'localhost' aliases=[localhost] addrs=[]}})
ares-test-live.cc:98: Failure
Value of: (int)result.host_.addrs_.size()
Actual: 0
Expected: 1
[ FAILED ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/1, where GetParam() = "b" (32 ms)
[ RUN ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/2
HostCallback({ARES_SUCCESS {'localhost' aliases=[localhost] addrs=[]}})
ares-test-live.cc:98: Failure
Value of: (int)result.host_.addrs_.size()
Actual: 0
Expected: 1
[ FAILED ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/2, where GetParam() = "fb" (31 ms)
[ RUN ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/3
HostCallback({ARES_SUCCESS {'localhost' aliases=[localhost] addrs=[]}})
ares-test-live.cc:98: Failure
Value of: (int)result.host_.addrs_.size()
Actual: 0
Expected: 1
[ FAILED ] Modes/DefaultChannelModeTest.LiveGetLocalhostByNameV6/3, where GetParam() = "bf" (47 ms)

Windows: arestest and mixing CRTs

Several test/*.cc files have problems when cares.dll and arestest.exe was linked to separate CRTs.
E.g. compiling with /MTd, and passing a FILE* to/from C-ares and the application, triggers DbgReport like these:

caresd!_CrtDbgReportW(int report_type = 0n2, wchar_t * file_name = 0x6875b168 "minkernel\crts\ucrt\src\appcrt\lowio\read.cpp", int line_number = 0n378, wchar_t * module_name = 0x00000000 "", wchar_t * format = 0x6873fbf0 "%ls")+0x34
caresd!_read(int fh = 0n3, void * buffer = 0x04842b58, unsigned int buffer_size = 0x1000)+0x144
caresd!common_refill_and_read_nolock<char>(class __crt_stdio_stream stream = class__crt_stdio_stream)+0x155
caresd!__acrt_stdio_refill_and_read_narrow_nolock(struct _iobuf * stream = 0x04826500)+0x1a
caresd!_fgetc_nolock(struct _iobuf * public_stream = 0x04826500)+0xca
caresd!_getc_nolock(struct _iobuf * stream = 0x04826500)+0xe
caresd!__crt_char_traits<char>::getc_nolock<_iobuf *>(struct _iobuf ** <args_0> = 0x00faef80)+0x10
caresd!common_fgets<char>(char * string = 0x04841c88 "???", int count = 0n4, class __crt_stdio_stream stream = class __crt_stdio_stream)+0x223
caresd!fgets(char * string = 0x04841c88 "???", int count = 0n4, struct _iobuf * stream = 0x04826500)+0x22
caresd!ares__read_line(struct _iobuf * fp = 0x04826500, char ** buf = 0x00faf23c, unsigned int * bufsize = 0x00faf248)+0x8e
arestest!ares::test::LibraryTest_ReadLine_Test::TestBody(void)+0xb9

A case from LibraryTest.ReadLine:

  FILE *fp = fopen(temp.filename(), "r");
  ...
  EXPECT_EQ(ARES_SUCCESS, ares__read_line(fp, &buf, &bufsize));

In this case, one cannot pass this fp across CRT boundaries.
But what options do we have? A new ares_open_file() function?

And in another case, mixing memory blocks across CRTs triggers similar reports.

Why ares_gethostbyname query only AF_INET6 if family parameter set to AF_UNSPEC?

By default POSIX getaddrinfo return both(either IPv4 and IPv6) if family set to AF_UNSPEC.

Certificate mismatch in https://c-ares.haxx.se/

Same problem as discussed in libssh2/libssh2#78

update version numbers

c-ares version 1.13.0 is apparently released, but is still versioned as 1.12.1-dev

Conan package

Hello,
Do you know about Conan?
Conan is modern dependency manager for C++. And will be great if your library will be available via package manager for other developers.

Here you can find example, how you can create package for the library.

If you have any questions, just ask :-)

Failed to launch App if the client host leave the DNS field blank

Steps:

Client machines not joined to domain and only one NIC.
In Windows Network and Internet setting, Specify IP address explicit and leave the DNS server field blank in the IPv4 settings
Launch App which use libcurl/c-ares 1.11

Result:
App failed to launch.

Note:
c-ares 1.10 doesn't have the issue.

Workaround
Join client machine to the domain or populate the IPv4 settings with a DNS server, does not have to be a valid IP address, or more than one NIC

v1.12.0, verision is '-', how to fix it?

pkg-config --modversion libcares.pc
version is '-'

DNS suffix issue

1.Compile curl/c-ares 1.13.0
2.Specify primary DNS suffix GPO such as abc.com in Windows.(Computer configuration->Administrative template->Network->DNS client->primary DNS suffix)
3.
curl -v host1

Rebuilt URL to: host1/
Could not resolve: host1(Domain name not found)
Closing connection 0
curl: (6) Could not resolve:host1 (Domain name not found)

curl -v host1.abc.com

Rebuilt URL to: host1.abc.com/
Trying 192.84.36.16...
TCP_NODELAY set
Connected to host1.abc.com (192.84.36.16) port 80 (#0)

GET / HTTP/1.1

The 1.13.0 release note added support for Windows DNS Suffix Search List, there is still problem?
Thanks!

README claims 'best practices' from some unrelated project

Link in README is to https://best practices.coreinfrastructure.org/projects/289.

Obviously the space is unwanted.

I'd submit a pull request fixing, but the fixed link takes me to some other project altogether ("JSON for Modern C++"). So I guess c-ares is also displaying that project's badge, and not its own.

I don't know how to guess what the correct link is.

Documentation misses buildconf command

Hi,

When downloading the cares-1_12_0 release from GitHub, the INSTALL file says that building from source should start with the following command (pretty standard):
./configure --help

However, this results in an error:
-bash: ./configure: No such file or directory

One way to fix this is to run the following command first, which should probably be mentioned in the INSTALL file:
./buildconf

Building with 'CURLDEBUG' fails

Currently building cares with -DCURLDEBUG fails:

ares__close_sockets.c
f:\MingW32\src\inet\curl\lib\../lib/memdebug.h(38): error C2054: expected '(' to follow 'CURL_EXTERN'
f:\MingW32\src\inet\curl\lib\../lib/memdebug.h(38): error C2085: 'curl_domalloc': not in formal parameter list
...

Seems to be a simple fix though:

--- a/ares_private.h 2016-04-30 10:37:07
+++ b/ares_private.h 2017-01-10 18:12:19
@@ -356,6 +356,7 @@
    libcurl lowlevel code from within library is ugly and only works when
    c-ares is built and linked with a similarly curldebug-enabled libcurl,
    but we do this anyway for convenience. */
+#include <curl/curl.h>
 #define HEADER_CURL_SETUP_ONCE_H
 #include "../lib/memdebug.h"
 #endif

c-ares doesn't use NRPT/DNSSEC configuration

c-ares 1.13.0 in Windows doesn't use Name Resolution Policy Table https://technet.microsoft.com/en-us/library/ee649207(v=ws.10).aspx

Configured DNSSEC in Domain/DNS server, push the nrpt group policy to client host as below
c-ares doesn't query OPT to require DNS validation, and it also doesn't read the GenericDNSServers setting if configured the genericDNSServers.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig{9913d84a-bb46-48e2-bacb-3dc8fcf62ab8}]
"ConfigOptions"=dword:0000000a
"Name"=hex(7):2e,00,73,00,65,00,63,00,2e,00,64,00,65,00,66,00,2e,00,63,00,6f,
00,6d,00,00,00,00,00
"IPSECCARestriction"=""
"DNSSECValidationRequired"=dword:00000001
"DNSSECQueryIPSECRequired"=dword:00000000
"DNSSECQueryIPSECEncryption"=dword:00000000
"GenericDNSServers"="10.117.46.1"
"Version"=dword:00000001

Windows: Support static CRT runtime in CMakeLists.txt

Something like that https://github.com/grpc/grpc/blob/master/cmake/msvc_static_runtime.cmake

SOA records can't be parsed from a ns_t_any response

I am trying to parse the response of ns_t_any request records but due to the way ares_parse_soa_reply is implemented it can't be parsed.

ares_parse_soa_reply explicitly expect the answer record count to be 1 in the answer buffer hence it always returns ARES_EBADRESP, normally it should loop through all the records to find the SOA record if none is found then it should return bad response (as per RFC)

Fails to build using MSVC 2015: Unknown value for _NMAKE_VER macro: 14.00.23918.0

dns suffix issue in 1.13.0

The dns suffix support in c-ares 1.13.0 is still unstable, Input the single-label unqualified server name, e.g. abc

some client hosts joined domain and append dns suffix suchas xyz.com
C:\temp\1.13.0>curl -v https://abc

Rebuilt URL to: https://abc/
Could not resolve: abc (Domain name not found)
Closing connection 0
curl: (6) Could not resolve: abc (Domain name not found)
MS ping/nslookup or IE doesn't have the issue in the hosts.

Add timeout for each query?

Any plan to add a timeout parameter for each query function?

C++11 language features is required

Im trying to compile c-ares on a very old CentOS 5.11 distribution. I understood c-ares is a C based library but I see configure looking for C++ 11 support. Why ?

$ uname -a
Linux c564 2.6.18-402.el5 #1 SMP Tue Feb 10 17:49:04 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and here the error:

checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... no
checking whether g++ supports C++11 features with -std=c++0x... no
configure: error: *** A compiler with support for C++11 language features is required.
configure: error: ./configure failed for test

Can I disable this during configure or do I really need to use a much newer compiler for C ++ ?

thanks

DNS Resolve issue after set multiple DNS servers

OS: Windows
c-ares version: 1.13.0
Steps:

Untick ipv6 setting.
Configure Preferred and Alternative DNS servers in windows network setting.
Launch curl/c-ares to connect to a FQDN which only preferred DNS server can resolve.
Result:

Rebuilt URL to: https://xxx.com
Could not resolve: xxx.com (Domain name not found)
Closing connection 0
curl: (6) Could not resolve: xxx.com (Domain name not found)

Query DNS Server from the disconnected adapter

Laptop has wireless and wired network cards.
The two cards can connected to two network connection and DNS servers can be reachable by the two different dhcp network type.

Steps
1.in the Lan network, go to DNS server 1 and then set web server DNS record to a server ip, such as 192.168.0.100

in the wireless network, go to DNS server2 and then set web server DNS record to a server ip, such as 192.168.0.200

3.Set Local Area Connection(wired connection) and Wireless Network connection both obtain and IP address/DNS server address automatically

4.Go to network connections->Advanced Settings->Adapters and Bindings, make sure Wireless Network connection at the top of local Area connection.

5.disconnect wireless connection, connected the local area connection(wired connection)

6.Launch app and try to connect to the web server

Result:
c-ares will query dns server2 and return the 192.168.0.200 for the web server.

c-ares 1.10

ares_init.c Line 1026

static int get_DNS_AdaptersAddresses(char *outptr)
{
…
for (ipaaEntry = ipaa; ipaaEntry; ipaaEntry = ipaaEntry->Next)
{
// Need to Add code to check the status !!!
/ Ignore the network interface if it is already down */
if( ipaaEntry->OperStatus != IfOperStatusUp )
continue;
for (ipaDNSAddr = ipaaEntry->FirstDnsServerAddress;
ipaDNSAddr;
ipaDNSAddr = ipaDNSAddr->Next)
{

c-ares tag issue

Hi,

All the c-ares tags have -DEV suffixed to the version number in ares_version.h as follows:

define ARES_VERSION_STR "1.11.1-DEV"

Why is that? The release tarballs do not have a -DEV in there.

c-ares on linux searches for "dns" in nsswitch.conf

Some Linux distributions, and especially in containers, might not use nss_dns at all in favour for nss_resolve from systemd. c-ares seems to specifically check for "dns" in /etc/nsswitch.conf.

For ex. this example https://gist.github.com/mopemope/992777 fails with:

$ grep hosts /etc/nsswitch.conf 
hosts: files resolve mymachines myhostname
$ ./async_dns 
Failed to lookup Could not contact DNS servers
fin

works when there's "dns":

$ grep hosts /etc/nsswitch.conf 
hosts: files resolve mymachines myhostname dns

c-ares 1.10.0-2

coredump

[root@localhost test]# make test
make  check-TESTS
make[1]: Entering directory '/home/xmly/thirdparty/c-ares/c-ares/test'
make[2]: Entering directory '/home/xmly/thirdparty/c-ares/c-ares/test'
*** Error in `/home/xmly/thirdparty/c-ares/c-ares/test/.libs/lt-arestest': double free or corruption (out): 0x0000000001126000 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x75dbb)[0x7f9c74922dbb]
/lib64/libc.so.6(+0x7e56a)[0x7f9c7492b56a]
/lib64/libc.so.6(cfree+0x4c)[0x7f9c7492eacc]
/home/xmly/thirdparty/c-ares/c-ares/test/.libs/lt-arestest[0x41d401]
/home/xmly/thirdparty/c-ares/c-ares/.libs/libcares.so.2(+0x3eb9)[0x7f9c75738eb9]
/home/xmly/thirdparty/c-ares/c-ares/.libs/libcares.so.2(+0x42ff)[0x7f9c757392ff]
/home/xmly/thirdparty/c-ares/c-ares/.libs/libcares.so.2(+0xc5eb)[0x7f9c757415eb]
======= Memory map: ========
00400000-00576000 r-xp 00000000 fd:00 395746                             /home/xmly/thirdparty/c-ares/c-ares/test/.libs/lt-arestest
00776000-00777000 r--p 00176000 fd:00 395746                             /home/xmly/thirdparty/c-ares/c-ares/test/.libs/lt-arestest
00777000-00778000 rw-p 00177000 fd:00 395746                             /home/xmly/thirdparty/c-ares/c-ares/test/.libs/lt-arestest
00778000-00779000 rw-p 00000000 00:00 0 
010d7000-0126d000 rw-p 00000000 00:00 0                                  [heap]
7f9c70000000-7f9c70021000 rw-p 00000000 00:00 0 
7f9c70021000-7f9c74000000 ---p 00000000 00:00 0 
7f9c74492000-7f9c7449a000 r-xp 00000000 fd:00 1056500                    /usr/lib64/libnss_sss.so.2
7f9c7449a000-7f9c74699000 ---p 00008000 fd:00 1056500                    /usr/lib64/libnss_sss.so.2
7f9c74699000-7f9c7469a000 r--p 00007000 fd:00 1056500                    /usr/lib64/libnss_sss.so.2
7f9c7469a000-7f9c7469b000 rw-p 00008000 fd:00 1056500                    /usr/lib64/libnss_sss.so.2
7f9c7469b000-7f9c746a6000 r-xp 00000000 fd:00 1056488                    /usr/lib64/libnss_files-2.23.so
7f9c746a6000-7f9c748a5000 ---p 0000b000 fd:00 1056488                    /usr/lib64/libnss_files-2.23.so
7f9c748a5000-7f9c748a6000 r--p 0000a000 fd:00 1056488                    /usr/lib64/libnss_files-2.23.so
7f9c748a6000-7f9c748a7000 rw-p 0000b000 fd:00 1056488                    /usr/lib64/libnss_files-2.23.so
7f9c748a7000-7f9c748ad000 rw-p 00000000 00:00 0 
7f9c748ad000-7f9c74a66000 r-xp 00000000 fd:00 1055981                    /usr/lib64/libc-2.23.so
7f9c74a66000-7f9c74c66000 ---p 001b9000 fd:00 1055981                    /usr/lib64/libc-2.23.so
7f9c74c66000-7f9c74c6a000 r--p 001b9000 fd:00 1055981                    /usr/lib64/libc-2.23.so
7f9c74c6a000-7f9c74c6c000 rw-p 001bd000 fd:00 1055981                    /usr/lib64/libc-2.23.so
7f9c74c6c000-7f9c74c70000 rw-p 00000000 00:00 0 
7f9c74c70000-7f9c74c87000 r-xp 00000000 fd:00 1056580                    /usr/lib64/libpthread-2.23.so
7f9c74c87000-7f9c74e86000 ---p 00017000 fd:00 1056580                    /usr/lib64/libpthread-2.23.so
7f9c74e86000-7f9c74e87000 r--p 00016000 fd:00 1056580                    /usr/lib64/libpthread-2.23.so
7f9c74e87000-7f9c74e88000 rw-p 00017000 fd:00 1056580                    /usr/lib64/libpthread-2.23.so
7f9c74e88000-7f9c74e8c000 rw-p 00000000 00:00 0 
7f9c74e8c000-7f9c74ea2000 r-xp 00000000 fd:00 1058940                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f9c74ea2000-7f9c750a1000 ---p 00016000 fd:00 1058940                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f9c750a1000-7f9c750a2000 r--p 00015000 fd:00 1058940                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f9c750a2000-7f9c750a3000 rw-p 00016000 fd:00 1058940                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f9c750a3000-7f9c751ac000 r-xp 00000000 fd:00 1056409                    /usr/lib64/libm-2.23.so
7f9c751ac000-7f9c753ab000 ---p 00109000 fd:00 1056409                    /usr/lib64/libm-2.23.so
7f9c753ab000-7f9c753ac000 r--p 00108000 fd:00 1056409                    /usr/lib64/libm-2.23.so
7f9c753ac000-7f9c753ad000 rw-p 00109000 fd:00 1056409                    /usr/lib64/libm-2.23.so
7f9c753ad000-7f9c75525000 r-xp 00000000 fd:00 1058414                    /usr/lib64/libstdc++.so.6.0.22
7f9c75525000-7f9c75725000 ---p 00178000 fd:00 1058414                    /usr/lib64/libstdc++.so.6.0.22
7f9c75725000-7f9c7572f000 r--p 00178000 fd:00 1058414                    /usr/lib64/libstdc++.so.6.0.22
7f9c7572f000-7f9c75731000 rw-p 00182000 fd:00 1058414                    /usr/lib64/libstdc++.so.6.0.22
7f9c75731000-7f9c75735000 rw-p 00000000 00:00 0 
7f9c75735000-7f9c75746000 r-xp 00000000 fd:00 394858                     /home/xmly/thirdparty/c-ares/c-ares/.libs/libcares.so.2.2.0
7f9c75746000-7f9c75945000 ---p 00011000 fd:00 394858                     /home/xmly/thirdparty/c-ares/c-ares/.libs/libcares.so.2.2.0
7f9c75945000-7f9c75946000 r--p 00010000 fd:00 394858                     /home/xmly/thirdparty/c-ares/c-ares/.libs/libcares.so.2.2.0
7f9c75946000-7f9c75947000 rw-p 00011000 fd:00 394858                     /home/xmly/thirdparty/c-ares/c-ares/.libs/libcares.so.2.2.0
7f9c75947000-7f9c7596a000 r-xp 00000000 fd:00 1055811                    /usr/lib64/ld-2.23.so
7f9c75b3f000-7f9c75b46000 rw-p 00000000 00:00 0 
7f9c75b68000-7f9c75b6a000 rw-p 00000000 00:00 0 
7f9c75b6a000-7f9c75b6b000 r--p 00023000 fd:00 1055811                    /usr/lib64/ld-2.23.so
7f9c75b6b000-7f9c75b6c000 rw-p 00024000 fd:00 1055811                    /usr/lib64/ld-2.23.so
7f9c75b6c000-7f9c75b6d000 rw-p 00000000 00:00 0 
7ffeee9ca000-7ffeee9eb000 rw-p 00000000 00:00 0                          [stack]
7ffeee9ed000-7ffeee9f0000 r--p 00000000 00:00 0                          [vvar]
7ffeee9f0000-7ffeee9f2000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
./../test-driver: line 107: 29062 Segmentation fault      (core dumped) "$@" > $log_file 2>&1
FAIL: arestest
PASS: fuzzcheck.sh
============================================================================
Testsuite summary for c-ares-test -
============================================================================
# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to -
============================================================================
Makefile:1083: recipe for target 'test-suite.log' failed
make[2]: *** [test-suite.log] Error 1
make[2]: Leaving directory '/home/xmly/thirdparty/c-ares/c-ares/test'
Makefile:1189: recipe for target 'check-TESTS' failed
make[1]: *** [check-TESTS] Error 2
make[1]: Leaving directory '/home/xmly/thirdparty/c-ares/c-ares/test'
Makefile:1402: recipe for target 'check-am' failed
make: *** [check-am] Error 2
[root@localhost test]#

configure gets stuck at "checking types of args and return type for recvfrom"

Trying to build using mingw on msys2.

make install: Install nameser.h?

The header file nameser.h seems c-ares internal, but the definitions inside seem useful to many, e.g. gRPC uses them directly in their wrappers.

Both autotools and the CMake build do not add this file on make install - would it make sense to add it?

c-ares-1.12.0.tar.gz doesn't include msvc_ver.inc

The file's in the repository and seems to be required by Makefile.msvc.

ares_build.h (1.13.0) contains a wrong #define for ssize_t

#else
#  define CARES_TYPEOF_ARES_SSIZE_T ssize_t;
#endif

There is Semicolon at the end, which is wrong and causes a compile error on platforms where configure can't be used.

ares_build.h:207:37: error: declaration does not declare anything [-fpermissive]
 #  define CARES_TYPEOF_ARES_SSIZE_T ssize_t;
                                     ^

Cut new release?

Its been a good while since a version was released. Suggesting it'd be a good time to cut a new one? This allows nodejs to (optionally) link against it.

ares_init(&channel) returns unexpected status ARES_EBADNAME

While trying to initialize channel with following code,

    #include <ares.h>
    #include <stdio.h>

    int main() {
        int status;
        ares_channel channel;
        status = ares_library_init(ARES_LIB_INIT_ALL);
        printf("ares_library_init() status : (%d) %s\n", status, ares_strerror(status));
        if (status) {
            return 1;
        }
        status = ares_init(&channel);
        printf("ares_init(&channel) status : (%d) %s\n", status, ares_strerror(status));
        if (status) {
            ares_library_cleanup();
            return 1;
        }
        ares_destroy(channel);
        ares_library_cleanup();
        return 0;
    }

the function ares_init(&channel) returns ARES_EBADNAME (status=8).

The outputs:

    ares_library_init() status : (0) Successful completion
    ares_init(&channel) status : (8) Misformatted domain name
    Error: init_by_defaults failed: Misformatted domain name

This returned status is not any one of the four possible values as described in the document.
(i.e. ARES_SUCCESS, ARES_EFILE, ARES_ENOMEM, ARES_ENOTINITIALIZED)

I'm on Windows 7, MSYS2 mingw64 Shell, using
mingw-w64-x86_64-gcc version 7.2.0 and
mingw-w64-x86_64-c-ares version 1.13.0

AAAA response handling

When AWS returns a NS record for a AAAA query the c-ares library interprets this as an invalid response and retries the AAAA query using the search list. This causes the original query to not be properly resolved and results in unnecessary additional queries for each search list domain.

I took another look at the packet trace and it looks like this also happens when the AAAA record is no host. I think ares should be happy with the valid IPv4 response and still not start using the search list.

configure fails with non-C++11 compatible compiler

Regular configure tries to run the configure script in the test directory by default, and that requires C++11. Hence c-ares build is no longer compatible with a plain C89 compiler. Is there an easy way of turning this off short of hacking out the AC_CONFIG_SUBDIRS line for the test directory?

...
config.status: creating Makefile
config.status: creating libcares.pc
config.status: creating ares_config.h
config.status: creating ares_build.h
config.status: executing depfiles commands
config.status: executing libtool commands
=== configuring in test (/builddir/build/BUILD/c-ares-1.11.0/test)
configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr'  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--disable-silent-rules' '--disable-static' '--enable-shared' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --cache-file=/dev/null --srcdir=.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for x86_64-redhat-linux-gnu-g++... no
checking for x86_64-redhat-linux-gnu-c++... no
checking for x86_64-redhat-linux-gnu-gpp... no
checking for x86_64-redhat-linux-gnu-aCC... no
checking for x86_64-redhat-linux-gnu-CC... no
checking for x86_64-redhat-linux-gnu-cxx... no
checking for x86_64-redhat-linux-gnu-cc++... no
checking for x86_64-redhat-linux-gnu-cl.exe... no
checking for x86_64-redhat-linux-gnu-FCC... no
checking for x86_64-redhat-linux-gnu-KCC... no
checking for x86_64-redhat-linux-gnu-RCC... no
checking for x86_64-redhat-linux-gnu-xlC_r... no
checking for x86_64-redhat-linux-gnu-xlC... no
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... none
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... no
checking whether g++ supports C++11 features with -std=c++0x... no
configure: error: *** A compiler with support for C++11 language features is required.
configure: error: ./configure failed for test

dnsdump heap-error in debug-mode

With a dnsdump.exe built with MSVC-2015 in debug-mode (-MDd), this single test:

dnsdump.exe test\fuzzinput\004a216d3cff18b0c5c6b68b807f1529

throws a debug-assert as this:

The call-stack (from WinDbg) is:

dnsdump!free_dbg_nolock(void * block = 0x04420568, int block_use = 0n1)+0x44b [minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp @ 996] 
dnsdump!_free_dbg(void * block = 0x04420568, int block_use = 0n1)+0x7c [minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp @ 1030] 
dnsdump!free(void * block = 0x04420568)+0x20 [minkernel\crts\ucrt\src\appcrt\heap\free.cpp @ 28] 
dnsdump!ares::QuestionToString(class std::vector<unsigned char,std::allocator<unsigned char> > * packet = 0x012cfd3c { size=32 }, unsigned char ** data = 0x012cf7b4, int * len = 0x012cf8a4)+0x32e [f:\mingw32\src\inet\dns\c-ares\test\dns-proto.cc @ 251] 
dnsdump!ares::PacketToString(class std::vector<unsigned char,std::allocator<unsigned char> > * packet = 0x012cfd3c { size=32 })+0x6c4 [f:\mingw32\src\inet\dns\c-ares\test\dns-proto.cc @ 213] 
dnsdump!ares::ShowFile(char * filename = 0x036aee50 "test\fuzzinput\004a216d3cff18b0c5c6b68b807f1529")+0x17b [f:\mingw32\src\inet\dns\c-ares\test\dns-dump.cc @ 29] 
dnsdump!main(int argc = 0n2, char ** argv = 0x036aee38)+0x34 [f:\mingw32\src\inet\dns\c-ares\test\dns-dump.cc @ 36] 
dnsdump!invoke_main(void)+0x1e [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 74] 
...

This looks like CRT-mixing issue like I saw in the GoogleTest programs. But the dnsdump.exe does not use this library.

From what I gather, the QuestionToString() gets name from:

  int rc = ares_expand_name(*data, packet.data(), packet.size(), &name, &enclen);

caresd.dll has it's own debug-CRT. And so has dnsdump.exe. Thus the call free(name) triggers this debug-error. AFAICS, all free(x) should be replaced with ares_free_string(x).

ares_getsock needs documentation and examples

I was trying to understand ares_process_fd() and it seems, in the current documentation, that there is no way to get the ares_socket_t of a channel.

Watching at the sources, it seems that there is an ares_getsock() function that should fit this purpose but it lacks documentation. Quite weird, as it seems that it was added back in 2010.

Please add documentation and a meanungful example.

There is a single none-ASCII character in acountry.c

Is this supposed to be UTF-8 ?

.../c-ares-1/acountry.c:276:22: warning: illegal character
      encoding in string literal [-Winvalid-source-encoding]
       { 248, "ax", "<C5>land Island"                         },
                     ^~~~
1 warning generated.

outdated ares_sock_state_cb doc

It should be

typedef void (*ares_sock_state_cb)(void *data,
                                   ares_socket_t socket_fd,
                                   int readable,
                                   int writable)

but the doc says

void (*\fIsock_state_cb\fP)(void *data, int s, int read, int write)

ref:

c-ares/ares.h

Line 227 in bcfbad9

ares_socket_t socket_fd,

c-ares/ares_init_options.3

Line 142 in 3aead6a

.B void (*\fIsock_state_cb\fP)(void *data, int s, int read, int write);

Generated CMake config file has errors

The generated CMake config file, when building using the CMake build system, tries to create ALIASes for IMPORTED targets, which is illegal.

getProp not working in Android O

The final APIs for Android O are out. As you may know, system properties net.dns1, net.dns2 (...) were removed from the API. So, c-Ares will not be able to get servers' addresses. An alternative will be to use ares_init_options and pass the servers as parameters, however it would be nice to have this working as previous.

This is the error in the logs:

E/libc: Access denied finding property "net.dns1"

Are you planning to fix this?

ares_init.c build fails with 'incompatible pointer type' under mingw on windows.

function next_suffix asks for const char** but pp is just char**

third_party/cares/cares/ares_init.c: In function 'get_SuffixList_Windows':
third_party/cares/cares/ares_init.c:1430:7: error: passing argument 1 of 'next_suffix' from incompatible pointer type [-Werror]
       while (len = next_suffix(&pp, len))
       ^
third_party/cares/cares/ares_init.c:1347:15: note: expected 'const char **' but argument is of type 'char **'
 static size_t next_suffix(const char** list, const size_t advance)

ares_gethostbyname resolving "localhost" on Windows

Resolving the hostname "localhost" should not involve DNS servers. Calling the windows API function gethostbyname with "localhost" does not create any UDP packets (it is also possible to turn-off/disable the Ethernet Adapter and gethostbyname with "localhost" still returns 127.0.0.1).
I did not found a documentation for the special handling of "localhost" but maybe the behavior for this part is similar to Windows getaddrinfo where the documentation says:

If the pNodeName parameter points to a string equal to "localhost", all loopback addresses on the local computer are returned.

Calling ares_gethostbyname on the other hand (e.g. ahost -t a localhost.) creates UDP packets. This is especially a problem if Issue #53 gets implemented which would lead to many DNS requests:

localhost.first.parameterized.suffix.com
localhost.second.parameterized.suffix.com
localhost.third.parameterized.suffix.com
...
localhost.

Crash on clock_gettime() on iOS when using configure

As per: 7518c26 there's a bug in xcode 8, leading to a crash when using clock_gettime(). This has been fixed when using cmake, but I'm using configure and still encountering it