Detected by clang

When a nameserver is down, we periodically try sending a "probe"
message to that nameserver to see if it has come back up.  If a
nameserver comes up, we cancel any pending probe messages.

Cancelling a probe message while handling the probe's response would
result in a access-after-free or a double-free, so when we notice that
we're about to call a nameserver up because of having received a probe
from it, we need to check whether current response is the response
from the probe.

There was a case where we didn't to that, though: when the resolver
gave us an unusual error response to our request that it resolve
google.com.  This is pretty rare, but apparently it can happen with
some weird cacheing nameservers -- the one on the mikrotik router, for
example.  Without this patch, we would crash with a NULL pointer
derefernce.

Thanks to Hannes Sowa for finding this issue and helping me track it
down.

If openssl is not installed system-wide or not compiled as a shared library,
some systems require various link flags (e.g., -ld).

Windows doesn't have a mode_t as far as I can tell.

Some unixes, iirc, don't like three-argument open without O_CREAT.

In a multi-process/threaded environment, opening fds internally
without the close-on-exec flag could leak fds to child processes.