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)
Add new extra functions getdns_yaml2(dict|list|bindata|value)(). These are like their getdns_str2() counterparts, but take YAML input rather than JSON.
YAML introduces a new dependency, on libyaml. YAML can be disabled at configuration time, in which case the dependency is removed.
Modify getdns_query such that if a configuration file name includes ".yaml" it will be processed as a YAML configuration, not a JSON configuration.
Internally, getdns_yaml2*() work by passing the YAML string through a simple translation to JSON. At present, this translation assumes that configuration is the only use case, and so will error if the outer layer of the YAML input is not a map. This in effect means that at present all getdns_yaml2*() functions apart from getdns_yaml2dict() will give an error on the YAML translation to JSON.
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.
2) Remove the OARC server from the default config. So now only include the servers that commit to not logging user data. Can make this clearer once we have a yaml config file.
3) Update makefile to include stubby.conf and stubby-setdns in dist tarball
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
Jim Hague
Sara Dickinson
Melinda Shore
Daniel Kahn Gillmor