The following post details on the impact of the root Key Signing Key rollover on getdns DNSSEC validation. With the KSK rollover in process and taking place on 11th of October, users must be aware of the different situations and actions needed for the different getdns versions.

getdns v1.1 and earlier

In the releases to-date getdns does not have automatic DNSSEC trust-anchor management included within the library. When installing getdns v1.1 or earlier from source, a message is displayed requesting the manual installation of a root trust-anchor with unbound-anchor using the command

> unbound-achor -a <trust_anchor_file>

The default location of the <trust_anchor_file> used by getdns in this case depends on the value of sysconfdir during configuring. Typically this could be /usr/local/etc/unbound/getdns-root.key or /etc/unbound/getdns-root.key.

Installations before 2nd of February

If the manual installation of the root trust-anchor was performed before 2nd February 2017 and no trust anchor management is performed externally to getdns, then another manual installation MUST be re-run before 11th October to obtain the new KSK in order to enable DNSSEC validation to continue after October 11th. The easiest way to determine this is to run

> getdns_query -k

-- if there is only 1 entry for a DNSKEY then the last update was most likely before 2nd February 2017.

Installations after 2nd of February

If the most recent manual installation of the root trust-anchor was performed after 2nd February 2017, then that operation also installed the new KSK and getdns is already equipped to perform DNSSEC validation after October 11th. This is because getdns parses the default trust-anchors file as a zone file and uses all the keys it finds (regardless of any annotations that unbound-anchor may have added). This is true in both stub and full recursive mode.

Also note that when used in a long running process getdns is not aware of updates to the trust-anchor file. Long running programs that use getdns to perform DNSSEC validation MUST be restarted after the trust-anchors have been manually updated for the changes to take effect.

getdns v1.2

We recognise that a dependency on external or manual trust-anchor management for a library intended for applications 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. Therefore the soon-to-be release version 1.2.0 of getdns will include 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, a new set of root trust-anchors will be fetched from https://data.iana.org/root-anchors/root-anchors.xml and validated with ICANN when a DNSSEC answer could not be validated and the root DNSKEY set is either seen for the first time or has changed.
Details about the precise operation of zero configuration DNSSEC will come with the getdns 1.2.0 release announcement.

We strongly recommend upgrading to getdns 1.2 as soon as possible for all users who perform DNSSEC validation. Details of the release dates of getdns will be announced on the getdns-users list.