| test: fuzzer input triggering double free (#315) OSS-Fuzz has reported a double-free with the fuzzer input file included here; run with: ./test/aresfuzz test/fuzzinput/clusterfuzz-5637790584012800 Bisecting the failure points to commit e0517f97d988 ("Parse SOA records from ns_t_any response (#103)") | 6 个月前 |
| test: add fuzz entrypoint for ares_create_query() | 9 年前 |
| Autotools: rework to simplify and fix recent issues (#674) Completely rework the autotools build system, issues have cropped up due to the complexity and could cause issues on even semi-modern Linux systems (Ubuntu 20.04 for example). Changes include: Remove all curl/xc/cares m4 helper files, they go overboard on detections of functions and datatypes. Go back to more plain autoconf macros as they've come a long way over the years. Use known systems and heuristics to determine datatypes for functions like send() and recv(), rather than the error prone detection which required thousands of permutations and might still get it wrong. Remove unneeded configure arguments like --enable-debug or --enable-optimize, its more common for people to simply pass their own CFLAGS on the command line. Only require CARES_STATICLIB definition on Windows static builds, its not necessary ever for other systems, even when hiding non-public symbols. Remove some function and definition detections that were never used in c-ares The test framework is now embedded into the toplevel configure system, there was no need to chain build the test system as it is never built externally to c-ares. As a side-effect of the changes, a configure run completes in about 25% of the original time. This has been tested on various Linux distributions (of varying age), FreeBSD, MacOS, Windows (via MSYS2 with Mingw), and Solaris10/11 (by @dfandrich), AIX 7.3 (by @dfandrich). It is not unlikely that this may have broken more esoteric or legacy systems, and we'll likely need to be ready to accept bug reports and patches, but it has removed over 10k lines of build system code. It is very likely any issues that crop up will add far fewer lines of code to fix such systems. Fixes Bug: #670 Fix By: Brad House (@bradh352) | 6 个月前 |
| | 6 个月前 |
| Auto reload config on changes (requires EventThread) (#759) Automatically detect configuration changes and reload. On systems which provide notification mechanisms, use those, otherwise fallback to polling. When a system configuration change is detected, it asynchronously applies the configuration in order to ensure it is a non-blocking operation for any queries which may still be being processed. On Windows, however, changes aren't detected if a user manually sets/changes the DNS servers on an interface, it doesn't appear there is any mechanism capable of this. We are relying on NotifyIpInterfaceChange() for notifications. Fixes Issue: #613 Fix By: Brad House (@bradh352) | 6 个月前 |
| Auto reload config on changes (requires EventThread) (#759) Automatically detect configuration changes and reload. On systems which provide notification mechanisms, use those, otherwise fallback to polling. When a system configuration change is detected, it asynchronously applies the configuration in order to ensure it is a non-blocking operation for any queries which may still be being processed. On Windows, however, changes aren't detected if a user manually sets/changes the DNS servers on an interface, it doesn't appear there is any mechanism capable of this. We are relying on NotifyIpInterfaceChange() for notifications. Fixes Issue: #613 Fix By: Brad House (@bradh352) | 6 个月前 |
| mark deprecated functions as such (#732) Multiple functions have been deprecated over the years, annotate them with attribute deprecated. When possible show a message about their replacements. This is a continuation/completion of PR #706 Fix By: Cristian Rodríguez (@crrodriguez) | 6 个月前 |
| msvc Makefiles: Remove support for MSVC 6 and 7 since we can't target legacy Windows versions supported by those compilers anymore | 6 个月前 |
| provide SPDX identifiers and a REUSE CI job to verify All files have their licence and copyright information clearly identifiable. If not in the file header, they are set separately in .reuse/dep5. All used license texts are provided in LICENSES/ | 6 个月前 |
| build fix | 6 个月前 |
| test: fix outdated license headers | 6 个月前 |
| fix comments | 6 个月前 |
| build fix | 6 个月前 |
| remove tests that have been disabled forever | 6 个月前 |
| CI: Add CentOS 7 build test to prevent future issues (#851) Issue #850 showed a regression on CentOS 7. Lets add a CI Test for that to prevent future issues. Authored-By: Brad House (@bradh352) | 6 个月前 |
| CI: Add CentOS 7 build test to prevent future issues (#851) Issue #850 showed a regression on CentOS 7. Lets add a CI Test for that to prevent future issues. Authored-By: Brad House (@bradh352) | 6 个月前 |
| tests: MacOS needs higher priority on CI systems (#849) On CI systems that can be overloaded, things like usleep() and select() may not closely honor their timeouts, and can often be a multiple of the requested timeout. Some tests, out of necessity need to rely on accurate timing in order to test timeout conditions so this means test failures when the skew is too large. Short of increasing timeouts to a point that would make tests take an unreasonable amount of time, the alternative is to make the OS honor the requested timeout more accurately. On MacOS this means to set a realtime thread priority for the tests. Other projects like libuv do this same thing. The code is taken from: https://developer.apple.com/library/archive/technotes/tn2169/_index.html Authored-By: Brad House (@bradh352) | 6 个月前 |
| CI: Add CentOS 7 build test to prevent future issues (#851) Issue #850 showed a regression on CentOS 7. Lets add a CI Test for that to prevent future issues. Authored-By: Brad House (@bradh352) | 6 个月前 |
| CI: Add CentOS 7 build test to prevent future issues (#851) Issue #850 showed a regression on CentOS 7. Lets add a CI Test for that to prevent future issues. Authored-By: Brad House (@bradh352) | 6 个月前 |
| tests: MacOS needs higher priority on CI systems (#849) On CI systems that can be overloaded, things like usleep() and select() may not closely honor their timeouts, and can often be a multiple of the requested timeout. Some tests, out of necessity need to rely on accurate timing in order to test timeout conditions so this means test failures when the skew is too large. Short of increasing timeouts to a point that would make tests take an unreasonable amount of time, the alternative is to make the OS honor the requested timeout more accurately. On MacOS this means to set a realtime thread priority for the tests. Other projects like libuv do this same thing. The code is taken from: https://developer.apple.com/library/archive/technotes/tn2169/_index.html Authored-By: Brad House (@bradh352) | 6 个月前 |
| Tests: add test case for searching with cache enabled (#853) Issue #852 says that searching with cache may be broken. Add a test case to verify. Authored-By: Brad House (@bradh352) | 6 个月前 |
| try to work around windows ASAN issue by not using std::string::npos | 6 个月前 |
| DNS 0x20 implementation (#800) This PR enables DNS 0x20 as per https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00 . DNS 0x20 adds additional entropy to the request by randomly altering the case of the DNS question to help prevent cache poisoning attacks. Google DNS has implemented this support as of 2023, even though this is a proposed and expired standard from 2008: https://groups.google.com/g/public-dns-discuss/c/KxIDPOydA5M There have been documented cases of name server and caching server non-conformance, though it is expected to become more rare, especially since Google has started using this. This can be enabled via the ARES_FLAG_DNS0x20 flag, which is currently disabled by default. The test cases do however enable this flag to validate this feature. Implementors using this flag will notice that responses will retain the mixed case, but since DNS names are case-insensitive, any proper implementation should not be impacted. There is currently no fallback mechanism implemented as it isn't immediately clear how this may affect a stub resolver like c-ares where we aren't querying the authoritative name server, but instead an intermediate recursive resolver where some domains may return invalid results while others return valid results, all while querying the same nameserver. Likely using DNS cookies as suggested by #620 is a better mechanism to fight cache poisoning attacks for stub resolvers. TCP queries do not use this feature even if the ARES_FLAG_DNS0x20 flag is specified since they are not subject to cache poisoning attacks. Fixes Issue: #795 Fix By: Brad House (@bradh352) | 6 个月前 |
| DNS 0x20 implementation (#800) This PR enables DNS 0x20 as per https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00 . DNS 0x20 adds additional entropy to the request by randomly altering the case of the DNS question to help prevent cache poisoning attacks. Google DNS has implemented this support as of 2023, even though this is a proposed and expired standard from 2008: https://groups.google.com/g/public-dns-discuss/c/KxIDPOydA5M There have been documented cases of name server and caching server non-conformance, though it is expected to become more rare, especially since Google has started using this. This can be enabled via the ARES_FLAG_DNS0x20 flag, which is currently disabled by default. The test cases do however enable this flag to validate this feature. Implementors using this flag will notice that responses will retain the mixed case, but since DNS names are case-insensitive, any proper implementation should not be impacted. There is currently no fallback mechanism implemented as it isn't immediately clear how this may affect a stub resolver like c-ares where we aren't querying the authoritative name server, but instead an intermediate recursive resolver where some domains may return invalid results while others return valid results, all while querying the same nameserver. Likely using DNS cookies as suggested by #620 is a better mechanism to fight cache poisoning attacks for stub resolvers. TCP queries do not use this feature even if the ARES_FLAG_DNS0x20 flag is specified since they are not subject to cache poisoning attacks. Fixes Issue: #795 Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| Add DNS cookie support (RFC7873 + RFC9018) (#833) DNS cookies are a simple form of learned mutual authentication supported by most DNS server implementations these days and can help prevent DNS Cache Poisoning attacks for clients and DNS amplification attacks for servers. Fixes #620 Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| DNS RR TXT strings should not be automatically concatenated (#801) As per #738, there are usecases where the DNS TXT record strings should not be concatenated like RFC 7208 indicates. We cannot break ABI with those using the new API, so we need to support retrieving the concatenated version as well as a new API to retrieve the individual strings which will be used by ares_parse_text_reply_ext() to restore the old behavior prior to c-ares 1.20. Fixes Issue: #738 Fix By: Brad House (@bradh352) | 6 个月前 |
| Coverage code annotations for identification of desirable paths that need testing (#775) Add code annotations for ignoring specific code paths for coverage calculations. The primary purpose of this is to make it easy to see the code paths that we could (and probably should) write test cases for, as these would have the most impact on delivery of a stable product. The annotations used are: LCOV_EXCL_LINE: <designation>, LCOV_EXCL_START: <designation>, LCOV_EXCL_STOP Unfortunately LCOV_EXCL_BR_LINE does not appear to be supported by coveralls as it would have been a more elegant solution over START/STOP. We specifically include the <designation> not just for future reference but because it makes it easy to identify in case we want to address these conditions in a different way in the future. The main areas designated for exclusion are: 1. OutOfMemory - these are hard to test cases, and on modern systems, are likely to never occur due to optimistic memory allocations, which can then later cause the kernel to terminate your application due to memory not actually being available. c-ares does have *some* testing framework for this, if we wish to expand in the future, we can easily use sed to get rid of of these annotations. 2. DefensiveCoding - these are impossible to reach paths at the point in time the code was written. They are there for defensive coding in case code is refactored in the future to prevent unexpected behavior. 3. UntestablePath - these are code paths that aren't possible to test, such as failure of a system call. 4. FallbackCode - This is an entire set of code that is untestable because its not able to simulate a failure of the primary path. This PR also does add some actual coverage in the test cases where it is easy to do. Fix By: Brad House (@bradh352) | 6 个月前 |
| test: fix outdated license headers | 6 个月前 |
| Implement TCP FastOpen (TFO) RFC7413 (#840) TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a client and server have previously communicated. The SYN packet will also contain the initial data packet from the client to the server. This means there should be virtually no slowdown over UDP when both sides support TCP FastOpen, which is unfortunately not always the case. For instance, 1.1.1.1 appears to support TFO, however 8.8.8.8 does not. This implementation supports Linux, Android, FreeBSD, MacOS, and iOS. While Windows does have support for TCP FastOpen it does so via completion APIs only, and that can't be used with polling APIs like used by every other OS. We could implement it in the future if desired for those using ARES_OPT_EVENT_THREAD, but it would probably require adopting IOCP completely on Windows. Sysctls are required to be set appropriately: - Linux: net.ipv4.tcp_fastopen: - 1 = client only (typically default) - 2 = server only - 3 = client and server - MacOS: net.inet.tcp.fastopen - 1 = client only - 2 = server only - 3 = client and server (typically default) - FreeBSD: net.inet.tcp.fastopen.server_enable (boolean) and net.inet.tcp.fastopen.client_enable (boolean) This feature is always-on, when running on an OS with the capability enabled. Though some middleboxes have impacted end-to-end TFO and caused connectivity errors, all modern OSs perform automatic blackholing of IPs that have issues with TFO. It is not expected this to cause any issues in the modern day implementations. This will also help with improving latency for future DoT and DoH implementations. Authored-By: Brad House (@bradh352) | 6 个月前 |
| Refactor connection handling (#839) Refactor some connection handling to reduce code duplication and to unify the TCP and UDP codepaths a bit more. This will make some future changes easier to make. This also does some structure renaming to better conform with current standards: - struct server_state -> ares_server_t - struct server_connection -> ares_conn_t - struct query -> ares_query_t Authored-by: Brad House (@bradh352) | 6 个月前 |
| clang-format | 6 个月前 |
| test: fix outdated license headers | 6 个月前 |
| test: fix outdated license headers | 6 个月前 |
| server cookie wasn't being passed back due to missing length During the implementation of server cookies, test cases were missing to validate the server cookie in a prior reply was passed back, and it turns out they were not. This also adds tests for verification. Fix By: Brad House (@bradh352) | 6 个月前 |
| Refactor connection handling (#839) Refactor some connection handling to reduce code duplication and to unify the TCP and UDP codepaths a bit more. This will make some future changes easier to make. This also does some structure renaming to better conform with current standards: - struct server_state -> ares_server_t - struct server_connection -> ares_conn_t - struct query -> ares_query_t Authored-by: Brad House (@bradh352) | 6 个月前 |
| provide SPDX identifiers and a REUSE CI job to verify All files have their licence and copyright information clearly identifiable. If not in the file header, they are set separately in .reuse/dep5. All used license texts are provided in LICENSES/ | 6 个月前 |