Replace usage of inet_addr() with ares_inet_pton() which is more appropriate and fixes issues with legitimate addresses like 255.255.255.0. IPv6 already used this.
Fixes#309
Fix By: Brad House (@bradh352)
ares_gethostbyname() was returning ESUCCESS when no A or AAAA record was found but a CNAME pointing nowhere was present. ENODATA should be returned instead, however the hosts pointer will still be present to provide the alias list.
* Return ENODATA if no valid A or AAAA record found
* Fix and update test ParseAReplyNoData.
* Add test for new ENODATA behaviour in ares_gethostbyname.
Fixes Bug #303
Fix By: @tjwalton
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
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.
Add a new ares_library_init_mem() initialization function for the
library which allows the library user to specify their own malloc,
realloc & free equivalents for use library-wide.
Store these function pointers in library-wide global variables,
defaulting to libc's malloc(), realloc() and free().
Change all calls to malloc, realloc and free to use the function pointer
instead. Also ensure that ares_strdup() is always available
(even if the local environment includes strdup(3)), and change the
library code to always use it.
Convert calls to calloc() to use ares_malloc() + memset
If an AF_UNSPEC query gets a valid response to its AAAA query,
but which has no IPv6 addresses in it, then the code chains on to
a A record query. However, the hostent from the AAAA response
was being leaked along the way (because it gets replaced before
the follow-on end_hquery() invocation).
Previously, when an ares_gethostbyname() searched with AF_UNSPEC and the
first AF_INET6 call only returned CNAMEs, the host_callback never
retried AF_INET.
This patch makes sure than on ARES_SUCCESS, the result of AF_INET6 is
taken as authoritative only if the result contains some addresses.
Make sure that the symbols are always exported and present in c-ares.
Make the headers prefixed with 'ares'.
Removed the inet_ntop.h version as it no longer features any content.
the target host has only A records, it automatically falls back to an
AF_INET lookup and gives you the A results. However, if the target host has
a CNAME record, this behaviour is defeated since the original query does
return some data even though ares_parse_aaa_reply() doesn't consider it
relevant. Here's a small patch to make it behave the same with and without
the CNAME.