Apparently nodejs is relying on the above behavior for legacy reasons. Add
sanity checks to the various optmask parameters where it makes sense.
See https://github.com/nodejs/node/pull/50800
Fix By: Brad House (@bradh352)
Regression from c-ares 1.19.1, ARES_OPT_UDP_PORT and ARES_OPT_TCP_PORT are
specified from the user in host-byte order, but there was a regression that
caused it to be read as if it was network byte order.
Fixes Bug: #640
Reported By: @Flow86
Fix By: Brad House (@bradh352)
c-ares does not have any concept of thread-safety. It has always been 100% up to the implementor to ensure they never call c-ares from more than one thread at a time. This patch adds basic thread-safety support, which can be disabled at compile time if not desired. It uses a single recursive mutex per channel, which should be extremely quick when uncontested so overhead should be minimal.
Fixes Bug: #610
Also sets the stage to implement #611
Fix By: Brad House (@bradh352)
c-ares init options defines a flag ARES_FLAG_NOSEARCH that is supposed to prevent search using configured domain suffixes, however when using ares_getaddrinfo() the flag was ignored and domain suffixes were used anyway.
Configuring zero domains to search also does not work (if ndomains == 0 default domain search list is loaded regardless of the flag ARES_OPT_DOMAINS being set).
This change adds a check for the ARES_FLAG_NOSEARCH in as_is_only() function that is used by ares_getaddrinfo() to decide if to try to query next possible name ( next_dns_lookup() )
Fix By: @petrvh
c-ares parses only antique version of options for timeout and number of retries from resolv.conf (`retrans` and `retry` are missing in modern documentation https://man7.org/linux/man-pages/man5/resolv.conf.5.html).
I add support of `attempts` and `timeout` options
Fix By: Ignat (@Kontakter)
The timeout calculation was occurring with millisecond precision, but on some systems, there is microsecond precision which could mean we'd tell a user a timeout time prior to the actual timeout.
Fixes Bug: #631
Fix By: Brad House (@bradh352)
When building for UWP (WindowsStore), additional headers are needed and some functions are not available. This also adds AppVeyor CI/CD support to catch these issues in the future.
Fix By: Deal (@halx99) and Brad House (@bradh352)
For historic reasons, we have users depending on ares_set_servers_*()
to return ARES_SUCCESS when passing no servers and actually *clear*
the server list. It appears they do this for test cases to simulate
DNS unavailable or similar. Presumably they could achieve the same
effect in other ways (point to localhost on a port that isn't in use).
But it seems like this might be wide-spread enough to cause headaches
so we just will document and test for this behavior, clearly it hasn't
caused "issues" for anyone with the old behavior.
See: https://github.com/nodejs/node/pull/50800
Fix By: Brad House (@bradh352)
This PR implements a query cache at the lowest possible level, the actual dns request and response messages. Only successful and `NXDOMAIN` responses are cached. The lowest TTL in the response message determines the cache validity period for the response, and is capped at the configuration value for `qcache_max_ttl`. For `NXDOMAIN` responses, the SOA record is evaluated.
For a query to match the cache, the opcode, flags, and each question's class, type, and name are all evaluated. This is to prevent matching a cached entry for a subtly different query (such as if the RD flag is set on one request and not another).
For things like ares_getaddrinfo() or ares_search() that may spawn multiple queries, each individual message received is cached rather than the overarching response. This makes it possible for one query in the sequence to be purged from the cache while others still return cached results which means there is no chance of ever returning stale data.
We have had a lot of user requests to return TTLs on all the various parsers like `ares_parse_caa_reply()`, and likely this is because they want to implement caching mechanisms of their own, thus this PR should solve those issues as well.
Due to the internal data structures we have these days, this PR is less than 500 lines of new code.
Fixes#608
Fix By: Brad House (@bradh352)
Some users use blacklist files like https://github.com/StevenBlack/hosts which
can contain 200k+ host entries all pointing to 0.0.0.0. Due to the merge
logic in the new hosts processor, all those entries will be associated as
aliases for the same ip address.
The first issue is that it attempts to check the status of all the hosts for
the merged entry, when it should only be checking the new hosts added to the
merged entry, so this caused exponential time as the entries got longer.
The next issue is if searching for one of those hosts, it would append all
the matches as cnames/aliases, but there is zero use for 200k aliases
being appended to a lookup, so we are artificially capping this to 100.
Bug report reference: https://bugs.gentoo.org/917400
Fix By: Brad House (@bradh352)
Brad House
petrvh
Daniel Stenberg
Christian Clauss
Ignat
Gregor Jasny
Douglas R. Reno