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.
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 :)
ubkey-pinning.c -o pubkey-pinning.lo
./pubkey-pinning.c: In function '_getdns_verify_pinset_match':
./pubkey-pinning.c:385: warning: 'prev' may be used uninitialized in this function
IX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -c ./context.c -o context.lo
./context.c: In function '_getdns_upstream_shutdown':
./context.c:760: warning: comparison between signed and unsigned