Automatic installation of new DNSSEC trust anchor
Most software for DNSSEC-validating resolvers now supports RFC 5011. Any resolver running such software can therefore automatically install the new public root KSK as a trust anchor.
Although RFC 5011 is designed so that (root) KSK rollovers can take place without the system administrator's intervention, it's important to check that your resolver's current installation/configuration does actually support automatic trust anchor installation. If a validating resolver doesn't have the new trust anchor installed by 11 October 2017, all internet domains will become unreachable for any user or application relying on that resolver.
In an earlier article we explained the different ways that validating resolver operators can install the new trust anchor on their systems and provided guidance tailored to the various resolver software packages.
In this article, we take a look at RFC 5011 and tell you what support the most popular resolver software products provide. In a follow-up piece, we'll explain how you can check that the new trust anchor is installed and working properly.
RFC 5011 is a protocol that lets a validating resolver implement the whole rollover process itself. First, the new public key (in the form of a DNSKEY record) is obtained from an authoritative server for the root zone (or another trust point). The record has a digital signature based on the old, trusted key pair, so the resolver is able to confirm the record's authenticity using the usual DNSSEC functionality. The SEP bit (Secure Entry Point bit; see RFC 3757) in the DNSKEY record tells the resolver that the KSK is valid.
At a later stage, the old public key can be removed from the list of trust anchors by setting the DNSKEY record's REVOKE flag. In other words, as well as being used to declare insecure key pairs invalid, this existing functionality now serves to clear out expired keys.
Because the method depends entirely on a trusted public key being present on the resolver side, it will work only with systems on which a trust anchor is already installed. Most resolver software developers therefore provide the current trust anchors hard-coded into their products as a matter of course.
The new key (KSK-2017) was published in the root zone on 11 July. You can request the current public keys from the root zone as follows:
dig +multiline . DNSKEY
The following output will then be obtained:
. 13775 IN DNSKEY 257 3 8 (
) ; KSK; alg = RSASHA256; key id = 19036
. 13775 IN DNSKEY 257 3 8 (
) ; KSK; alg = RSASHA256; key id = 20326
. 13775 IN DNSKEY 256 3 8 (
) ; ZSK; alg = RSASHA256; key id = 15768
The key with key ID 20326 is the new public KSK. The value 257 (set SEP-bit) tells you that this is a valid KSK.
For security reasons, RFC 5011 states that a new public KSK must not be added to the trust anchors for at least thirty days (the hold-down period). During that period, a resolver has to check at intervals not exceeding two weeks whether the new key is still present. Any resolver that has obtained the key as described will therefore activate it as a trust anchor in the period 10 to 24 August.
The most popular resolver software packages are listed below, with details of their RFC 5011 support status.
Supports RFC 5011 from version 9.7.0 ('managed-keys')
Manual installation from version 9.6.2 ('trusted-keys'), the first implementation of DNSSEC validation in BIND
Supports RFC 5011 from version 1.4.0 (managed keys in 'auto-trust-anchor-file')
Manual installation as static trust anchor for older versions (using 'unbound-anchor')
KSK-2017 trust anchor supplied with software from version 1.6.1
Release 1.6.5 fixes a problem with Unbound installations made between 11 September and 11 October of this year; operators who install Unbound in the near future should therefore use this latest version
Supports validation only from version 4.0; doesn't yet support RFC 5011
KSK-2017 trust anchor supplied with software from version 4.0.5
Upgrade or manual installation using the Lua interface
Manual installation required; Infoblox Nederland says users will be actively informed
Windows DNS Server
Supports RFC 5011 from Windows Server 2012
Manual installation for Windows Server 2008, the first implementation of DNSSEC in Windows (using the DNS Manager or the Dnscmd.exe tool)
Knot DNS Resolver
Manually/bootstrap using the '-k root.keys' option, either in 'trust_anchors.file', or using the 'trust_anchors.add' configuration option
Doesn't support RFC 5011
KSK-2017 trust anchor supplied with software from version 2.77
Manual installation required (from version 2.69, the first implementation of DNSSEC, using trust-anchors.conf)
Developer Simon Kelley says that versions older than 2.76 should no longer be used anyway, due to bugs in the validation element
Next step: testing
The list presented above, together with the information we previously provided about manual trust anchor updating, gives you a good basis for preparing your resolvers for the actual rollover (scheduled for this autumn). It's important to recognise that, in practice, an existing installation may differ considerably from those we describe. For example, the maintainer of an OS distribution may have added KSK-2017 to 'their' packages as a trust anchor. There is also the possibility of an installation running a new version of the resolver software, but with an outdated configuration.
The next step is to test whether everything is working as it should. That topic will be covered in a follow-up article, which we'll publish once all resolvers that support RFC 5011 should have activated the new trust anchor.