A delay of 1000ms was causing frequent lookup timeouts e.g. on 9.9.9.9. We hypothesise that the delay causes an internal timeout in the server to fire. So reduce the delay to a smaller value that seems to leave the test working but reduces the incidence of timeouts.
We observe this still leaves timeouts on TLS connections to 9.9.9.9. These seem to occur only on TLS connections, and reducing the delay much further does not alter the observed behaviour. We guess there is something else going on there.
Signatures of DNSKEYs, DSs, NSECs and NSEC3s can not be wildcard expansions when used with DNSSEC proofs.
Only direct queries for those types are allowed to be wildcard expansions.
This in response to https://unbound.net/downloads/CVE-2017-15105.txt, although getdns was not vulnerable for this specific issue.
The concurrent test works by sending a known good query synchronously,
and then sending asynchronous queries for three random TLDs followed by
the known good query. The latter should be answerable from cache, and so
give a result before at least one of the random TLDs.
If in monitoring mode, make output conform to Nagios norms. This starts with the probe type and result, so we need to save output generated during the operation and print it at the end.
If not in monitoring mode, make the formatting more expansive.
Add a new item tls_version to call_reporting, containing the OpenSSL version string for the name of the protocol used for the connection.
The test does a normal lookup, but first sets the cipher list to TLS1.3 only ciphers. This will cause a Bad Context error at search time, so we can tell if the underlying OpenSSL library lacks TLS 1.3. The check the call reporting for a TLS version of "TLSv1.3".
The time parse with pre-1.0.2 is a best effort, and relies on timegm() to convert struct tm in UTC to time_t. There being attractive alternative. Isn't C time handling grotty?
Checking for server support for keepalive means we need to know if the server did send a keepalive option to the client. This information is not currently exposed in getdns, so add a flag 'server_keepalive_received' to call_reporting. This is 0 if not received, 1 if received. If received, the actual timeout is in 'idle timeout in ms', though watch out for the overflow alternative.
Willem Toorop
Jim Hague
Sara Dickinson