Add a test script that runs the fuzzing command over the
corpus of DNS packets. This doesn't actually do any fuzzing
(it just runs them as inputs without generating any variations)
but it does ensure that the fuzzing entrypoint is still working.
For fuzz testing it is useful to start from a corpus of valid
packets, so fill out the test/fuzzinput/ directory with a bunch
of inputs.
These packets were generated by temporarily modifying the c-ares
process_answer() function to save off any incoming response messages.
On a build where MSAN has been manually set up (which involves
using an MSAN-instrumented version of the standard C++ library, see
https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo)
there's a warning about use of uninitialized memory here. It
might be a false positive, but the fix is trivial so include it.
The current approach for disabling tests is not a good solution because
it forces you to pass --disable-tests, rather than auto-detect if your
system can support the tests in the first place. Many (most?) systems
do not have C++11. This also causes issues when chain-building c-ares,
the hosting system needs to be updated to support passing this
additional flag if necessary, it doesn't seem reasonable to add this
requirement which breaks compatibility.
This change auto-detects if the system can build the tests and
automatically disable them if it cannot. If you pass --enable-tests to
configure and the system cannot build them either due to lack of system
support, or because cross-compilation is being used, it will throw an
appropriate error since the user indicated they really did want the
tests.
For UDP tests, there's a chance of a retry. EXPECT_CALL only
expects a single request to arrive at the server; ON_CALL allows
for a UDP retry and repeats the same answer.
Note that ON_CALL and EXPECT_CALL can't be mixed in the same
test, and that tests that have a varied sequence of responses
for the same repeated request still have to use EXPECT_CALL.
Modern Linux systems may have libnss_resolve from systemd as the
resolver, which is then configured in /etc/nsswitch.conf with
the "resolve" keyword rather than "dns".
Fixes#33
After 46bb820be3 `init_by_resolv_conf`
errors are no longer swallowed in `ares_init_options`. This has exposed
a previously unknown bug in `lookups` initialization code.
If there is no lookup configuration in `resolv.conf`,
`init_by_resolv_conf` will attempt to read it from other files available
on the system. However, some of these files may have restricted
permissions (like `600`), which will lead to `EACCESS` errno, which in
turn is handled like a fatal error by `init_by_resolv_conf`.
However, it sounds illogical that this error should be handled as a
fatal. There is a `init_by_defaults` call that overrides `lookups` with
default value, and certainly possible absence of lookup information is
the reason why this function exists in a first place!
I suggest handling any `fopen` errors as non-fatal ones, allowing to
pick up the `lookups` value from different config files, or to pick up
default value.
This function sets a callback that is invoked after the socket is
created, but before the connection is established. This is an ideal
time to customize various socket options.