Key "tls_auth_pin" == 1 when a pin from a pinset is used to authenticate the tls session, 0 otherwise
Key "tls_auth_pkix" == 1 when the cert was signed with a CA in the verification location, 0 if it was not PKIX authenticated and 2 if unkown (for example when a pinset was sufficient to authenticate the session)
Fix for issue mentioned below:
Scenario: 4 UDP steams corresponding to 4 IP's configured.
Outbound query is always sent to 1st IP in the list unless there is a timeout.
If there is a timeout, the next outbound query is sent to the 2nd IP in the list.
If the 1st IP still times out then the next 2n queries (this increases in powers of 2) go to the 2nd IP.
If the 2nd IP times out at any point, then queries are sent to the 3rd IP (following the same algorithm of 2n queries before reverting to the 2nd IP)
Observation: Even if there is no timeout on 2nd IP, some queries are still sent to 3rd IP.
From code: The stream is switched whenever there is a timeout. If 10 messages were sent to first IP and they all timeout , the stream is switched 10 times in the current code.
Suggestion: Switch stream only on the first timeout on a stream or ignore when the timeout occurs on a stream which is not the current_udp stream.
When using Stubby as a system DNS over TLS resolver with a Internet
connection that disconnects and reconnects from time to time there is often
a long waiting time (~20 minutes) after the connection reconnects before
DNS queries start to work again.
This is because in this particular case all the upstream TLS TCP
connections in Stubby are stuck waiting for upstream server response.
Which will never arrive since the host external IP address might have
changed and / or NAT router connection tracking entries for these TCP
connections might have been removed when the Internet connection
reconnected.
By default Linux tries to retransmit data on a TCP connection 15 times
before finally terminating it.
This takes 16 - 20 minutes, which is obviously a very long time to wait for
system DNS resolving to work again.
This is a real problem on weak mobile connections.
Thankfully, there is a "TCP_USER_TIMEOUT" per-socket option that allows
explicitly setting how long the network stack will wait in such cases.
Let's add a matching "tcp_send_timeout" option to getdns that allows
setting this option on outgoing TCP sockets.
For backward compatibility the code won't try to set it by default.
With this option set to, for example, 15 seconds Stubby recovers pretty
much instantly in such cases.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
for the query, just like connection setup timeout was, so fallback transport have a chance too when TCP connection setup is less well detectable (as with TCP_FASTOPEN on MacOS).
Before (FreeBSD 11), poll could be used to wait for the socket to
be writeable immediately. Now (since FreeBSD 12) this results in
infinite wait, so we just have to write immediately to work around
this.
Set the priority string to a concatenation of the connection cipher and curve strings, falling back to the context ones if the connection value isn't specified. Also get context.c to specify NULL for default context list and the opportunistic list for the connection, moving these library-specific quantities into the specific implementation.
tls_min_version & tls_max_version settings must cause
failure when not supported by the TLS library. Not during
configure time, but during connection setup so it doesn't
hamper alternative transports.
Willem Toorop
Philip Homburg
Shikha Sharma
Maciej S. Szmigiero
Jim Hague
Jim Hague