The const AddrInfo& argument to operator<< overload for AddrInfo can be
a nullptr unique_ptr. Handle this explicitly by printing {nullptr} if
the rest of the function cannot be safely executed.
Fix-by: Dan Noé <dpn@google.com>
This files references INT_MAX, but does not include limits.h. This can
cause a build failure on some platforms. Include limits.h if we have it.
Fix-by: Dan Noé <dpn@google.com>
* fix leak if naddress of particular type found
* fix segfault when wanted ttls count lesser than count of result records
* add fuzzer input files that trigger problems (from #263)
Reported-By: David Drysdale (@daviddrysdale)
Fix-By: Andrew Selivanov (@ki11roy)
* Service support has been added to getaddrinfo.
* ares_parse_a/aaaa_record now share code with the addrinfo parser.
* Private ares_addrinfo structure with useful extensions such as ttls (including cname ttls),
as well as the ability to list multiple cnames in chain of lookups
Work By: Andrew Selivanov @ki11roy
Some socket functions weren't exposed for use by other areas of the library. Expose
those and make use of them in ares__sortaddrinfo().
Fix By: Andrew Selivanov (@ki11roy)
Due to an order of incrementing the remaining queries and calling ares_query, on a bad domain
the registered callback wouldn't be called.
Bug: #248
Fixed-By: @kedixa
Fix link issues caused by missing library that appears to only be required on ARM (though
docs don't list this restriction). Doesn't hurt to require it everywhere.
Bug: #251
Fixed-By: Darrin Cullop (@dwcullop)
There are two possible causes for infinite loops fo NXDOMAIN, based on how many dots are in the domain name (one for < ARES_OPT_NDOTS and one for >= ARES_OPT_NDOTS), where it will repeat the same query over and over as the hquery->next_domain doesn't increment.
Fix By: @kedixa
When querying a .onion domain, it returns directly without setting bufp to NULL. A subsequent free() that occurs can cause a segmentation fault.
Fix By: Khaidi Chu (@XadillaX)
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
AIX attempts to include both nameser_compat.h and onameser_compat.h. It appears
the proper fix is to define _USE_IRS so that only nameser_compat.h is used.
Bug: #224
Fix By: Brad House (@bradh352)
ares_dup() calls ares_init_options() by making its own fake option
mask since the original mask isn't stored but ARES_OPT_RESOLVCONF
was always set, instead of conditionally set. This caused a crash
because ares_strdup() isn't NULL-safe if no custom path was set.
Made ares_dup() set ARES_OPT_RESOLVCONF conditionally.
Fix By: Brad House (@bradh352)
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
Fixes issue #207. Uses LinkProperties.getDomains() to get a list of search domains and adds them to the suffix list. This also adds a new helper function to split strings into an array based on multiple delimiters replacing multiple other functions for dealing with string splitting.
Submitter: John Schember (@user-none)
Fixes: #207
Approved-by: Brad House (@bradh352)
Join all global and connection specific suffix lists. Use 'HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\SearchList', 'HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Domain' as global suffix lists.
Fix By: @afalin
The imported TRANSFORM_MAKEFILE_INC function from curl used space indention
but the rest of the file used tabs. Go ahead and make it tabs for
consistency as well.
Committed By: Brad House
Silence warning about using src to determine number of bytes to copy.
In this case it doesn't matter whether it is `src` or `dest`. So there
is no functionality change.
Bug: #210
Fix By: @flyingdutchman23
When using a modern GCC to compile c-ares, there is a stringop-overflow warning.
This patch simply silences the false-positive warning, there is no actual code flaw.
Bug: https://github.com/c-ares/c-ares/pull/201
Fixed By: Andi Schnebinger @Iniesta8
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
These changes fix a few warnings emitted by recent versions of MSVC when compiling with -W4. Half of the changes are in Windows-specific code, and the other half should be safe no matter the compiler or OS.
The allocation function change is probably the only one that needs explanation. MSVC gives warnings about the function pointers not being stable across DLL boundaries or something to that effect, so for Windows, I've made them be called indirectly, which at least made the compiler happy. I can't say I've tested every linking combination on Windows with them before or after the change, but it seems harmless.
Fix By: Brad Spencer @b-spencer
PR: https://github.com/c-ares/c-ares/pull/192
* Harden and rationalize c-ares timeout computation
* Remove the rand() part of the timeout calculation completely.
When c-ares sends a DNS query, it computes the timeout for that request as follows:
timeplus = channel->timeout << (query->try_count / channel->nservers);
timeplus = (timeplus * (9 + (rand () & 7))) / 16;
I see two issues with this code. Firstly, when either try_count or channel->timeout are large enough, this can end up as an illegal shift.
Secondly, the algorithm for adding the random timeout (added in 2009) is surprising. The original commit that introduced this algorithm says it was done to avoid a "packet storm". But, the algorithm appears to only reduce the timeout by an amount proportional to the scaled timeout's magnitude. It isn't clear to me that, for example, cutting a 30 second timeout almost in half to roughly 17 seconds is appropriate. Even with the default timeout of 5000 ms, this algorithm computes values between 2812 ms and 5000 ms, which is enough to cause a slightly latent DNS response to get spuriously dropped.
If preventing the timers from all expiring at the same time really is desirable, then it seems better to extend the timeout by a small factor so that the application gets at least the timeout it asked for, and maybe a little more. In my experience, this is common practice for timeouts: applications expect that a timeout will happen at or after the designated time (but not before), allowing for delay in detecting and reporting the timeout. Furthermore, it seems like the timeout shouldn't be extended by very much (we don't want a 30 second timeout changing into a 45 second timeout, either).
Consider also the documentation of channel->timeout in ares_init_options():
The number of milliseconds each name server is given to respond to a query on the first try. (After the first try, the timeout algorithm becomes more complicated, but scales linearly with the value of timeout.) The default is five seconds.
In the current implementation, even the first try does not use the value that the user supplies; it will use anywhere between 56% and 100% of that value.
The attached patch attempts to address all of these concerns without trying to make the algorithm much more sophisticated. After performing a safe shift, this patch simply adds a small random timeout to the computed value of between 0 ms and 511 ms. I could see limiting the random amount to be no greater than a proportion of the configured magnitude, but I can't see scaling the random with the overall computed timeout. As far as I understand, the goal is just to schedule retries "not at the same exact time", so a small difference seems sufficient.
UPDATE: randomization removed.
Closes PR #187
Fix by: Brad Spencer
Dan Noé
Andrew Selivanov
Brad House
Brad House
kedixa
Darrin W. Cullop
Khaidi Chu
Christian Ammer
Fabrice Fontaine
Ben Noordhuis
Daniel Stenberg
Sarat Addepalli
Ruslan Baratov
flyingdutchman23
John Schember
afalin
Andi Schnebinger
David Drysdale
Brad Spencer
David Hotham
Tobias Nießen