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.
This commit changes the semantics of tls_query_padding_blocksize()
slightly. Where previously both 0 and 1 meant "no padding", this
commit changes 1 to mean "pad using a sensible policy".
At NDSS 2017's DNS privacy workshop, I presented an empirical study of
DNS padding policies:
https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-workshop-2017-programme#session3
The slide deck is here:
https://dns.cmrg.net/ndss2017-dprive-empirical-DNS-traffic-size.pdf
The resulting recommendation from the research is that a simple
padding policy is relatively cheap and still protective of metadata
when DNS traffic is encrypted:
* queries should be padded to a multiple of 128 octets
* responses should be padded to a multiple of 468 octets
Since getdns is only currently doing queries over tls, we only have to
implement the first part of this policy :)
Willem Toorop
Jim Hague
Sara Dickinson
Neil Cook
Daniel Kahn Gillmor
huitema