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 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; KSK; alg = RSASHA256; key id = 19036 . 13775 IN DNSKEY 257 3 8 ( AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN 7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5 LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8 efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7 pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws 9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ) ; KSK; alg = RSASHA256; key id = 20326 . 13775 IN DNSKEY 256 3 8 ( AwEAAYvxrQOOujKdZz+37P+oL4l7e35/0diH/mZITGjl p4f81ZGQK42HNxSfkiSahinPR3t0YQhjC393NX4TorSi TJy76TBWddNOkC/IaGqcb4erU+nQ75k2Lf0oIpA7qTCk 3UkzYBqhKDHHAr2UditE7uFLDcoX4nBLCoaH5FtfxhUq yTlRu0RBXAEuKO+rORTFP0XgA5vlzVmXtwCkb9G8GknH uO1jVAwu3syPRVHErIbaXs1+jahvWWL+Do4wd+lA+TL3 +pUk+zKTD2ncq7ZbJBZddo9T7PZjvntWJUzIHIMWZRFA jpi+V7pgh0o1KYXZgDUbiA1s9oLAL1KLSdmoIYM= ) ; 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.