06e6494b5d8b9404f439d5a98a3ab8f1f4b3557fb7aa3db005b021a6289b4229
Dear all,
We have a new feature release version 1.2.0 of getdns.
This release contains two new features:
and
Until now, we've assumed an external system component (like unbound-anchor
) to do the trust-anchor management for getdns, but this is not optimal.
Ideally applications that want to use DNSSEC validation, for example to perform DANE, would want to be able to rely on an application library to deliver DNSSEC, without requiring additional system configuration.
This release includes a form of built-in trust-anchor management modelled on RFC7958, that is suitable for a resolver library which can not assume reliable up-time and which we have named: Zero configuration DNSSEC.
With Zero configuration DNSSEC, the "root-anchors.xml
" file (from http://data.iana.org/root-anchors/root-anchors.xml) will be verified by validating the S/MIME signatures (stored separately in "root-anchors.p7s
") with the ICANN Root Certificate Authority.
Trust anchors from "root-anchors.xml
" will be used only when the accompanying "root-anchors.p7s
" matches and validates and when either:
/etc/unbound/getdns-root.key
or /usr/local/etc/unbound/getdns-root.key
), or set explicitly by the application with the getdns_context_set_dnssec_trust_anchors()
function, orThe "root-anchors.xml
" and "root-anchors.p7s
" files will be tried to read from a location for storing library specific data: ${HOME}/.getdns/
on Unix like systems (Linux, BSD's, MacOS) and %AppData%\getdns
on Windows.
When trust anchors from "root-anchors.xml
" are used, the root DNSKEY is also tracked (for changes) and a copy of it is stored in a "root.key
" file in the library specific data directory.
A (new) version of "root-anchors.xml
" and "root-anchors.p7s
" will be retrieved from data.iana.org
, when either:
root-anchors.xml
" or "root-anchors.p7s
" files were absent, orroot-anchors.xml
".Zero configuration DNSSEC assumes DNSSEC with the ICANN root trust-anchors and is configured to use the ICANN defaults defined in RFC7958, but all default parameters can be adapted to fit alternate DNS(SEC) roots, with:
getdns_context_set_trust_anchors_url()
getdns_context_set_trust_anchors_verify_CA()
getdns_context_set_trust_anchors_verify_email()
getdns_context_set_appdata_dir()
RFC7858 suggested a back-off period of one hour on failing TLS upstreams. However this is not a resilient and practical demeanor in practice when short-term network outages or connection loss caused, for example, by laptops going to sleep.
This release introduces a new TLS upstream failure management scheme in which the back-off time is incremented gradually from 1 second up, and doubled each retry with a maximum set by the getdns_context_set_tls_backoff_time()
function.
Also, back-off time is ignored when there are no more responding TLS upstreams and the upstream with the least amount of retries will be used for retrying first.
Stubby will be much more resilient against short term outages and connection losses with this scheme.
This release comes with an updated version of Stubby (version 0.1.3) with the new improvement to read configuration files in YAML format.
Previously Stubby would read configuration files in the JSON like format that is understood by getdns. However, the necessity to deal with opening and closing brackets and the lack of comments make it unsuitable for human consumption. YAML is much better readable and most importantly: can be annotated with comments and is as such a good fit for configuration files.
Stubby configuration files are now specified in YAML format by default. JSON format can still be used if it is given on the command line with the -C flag.
Don't forget that the --with-stubby
option needs to be used with configure when you want to build Stubby alongside the library.
When build with Stubby, there is an additional dependency on libyaml for the stubby
binary only.
Also note that the primary location for Stubby has moved to the dnsprivacy.org website.
* 2017-09-29: Version 1.2.0 * Bugfix of rc1: authentication of first query with TLS Thanks Travis Burtrum * A function to set the location for library specific data, like trust-anchors: getdns_context_set_appdata(). * Zero configuration DNSSEC - build upon the scheme described in RFC7958. The URL from which to fetch the trust anchor, the verification CA and email can be set with the new getdns_context_set_trust_anchor_url(), getdns_context_set_trust_anchor_verify_CA() and getdns_context_set_trust_anchor_verify_email() functions. The default values are to fetch from IANA and to validate with the ICANN CA. * Update of Stubby with yaml configuration file and logging from a certain severity support. * Fix tpkg exit status on test failure. Thanks Jim Hague. * Refined logging levels for upstream statistics * Reuse (best behaving) backed-off TLS upstreams when non are usable. * Let TLS upstreams back-off a incremental amount of time. Back-off time starts with 1 second and is doubled each failure, but will not exceed the time given by getdns_context_set_tls_backoff_time() * Make TLS upstream management more resilient to temporary outages (like laptop sleeps)