[getdns-api] KSK rollover impact on getdns

[Willem Toorop]

Dear All,

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 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 most recent 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.




KSK rollover	: https://www.icann.org/resources/pages/ksk-rollover
unbound-anchor	: https://unbound.net/documentation/unbound-anchor.html
RFC7958		: https://tools.ietf.org/html/rfc7958
users list	: https://getdnsapi.net/mailman/listinfo/users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 829 bytes
Desc: OpenPGP digital signature
URL: <http://getdnsapi.net/pipermail/spec/attachments/20170912/6ebf4624/attachment.bin>