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".
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.
- backoff time was not incrementing correctly
- best authentication information state was not being kept for shutdowns during setup (needed if e.g. hostname authentication failed during handshake).
Can deal with timed out queries that are answered anyway.
+ reset the upstream on failure always
(since requests are rescheduled for fallback by upstream_failed now anyway)
Centralise it into util-internal.h, remove duplicate definitions from mdns, and add new pseudo-functions _getdns_closesocket(), _getdns_poll() and _getdns_socketerror(). Convert error values to simple values and convert error checking to use _getdns_socketerror() and the simple values. The simple values can also be used with the result from getsockopt() with SO_ERROR in stub.c.
But limit re-tries for a given netreq to the total number of upstreams before failing. This should (roughly) allow 2 retries per upstream of the correct transport before bailing out. Otherwise we are stuck in a loop retrying forever!
Need to reset connection state if connections fail at setup and on read/write if there are no more messages queued.
This means we will back-off servers that fail, so we should think about using a shorter backoff default in stubby
because otherwise temporarily loss of the network connection will mean having to restart stubby.
Also some minor changes to logging.
If netreq->fd is not set to -1, then multiple functions close the
same socket. This causes major issues in multithread code where the
socket must not be closed multiple times as it may be owned by a
different thread.
Remove the currently processed netreq first, so it can be retries with another upstream/transport.
We MUST add netreq to the netreqs_by_query_id map even before we write to it, to have a reliable store of taken query ids.