ICANN is in the process of rolling over the KSK pair for the DNS root. In other words, the current cryptographic key pair that forms the basis of the DNSSEC infrastructure (KSK-2010) is being replaced by a new pair (KSK-2017).
ICANN replaces secret DNSSEC keys
The first part of this article explains the various ways that validating resolver operators can install the public part of the new key pair on their systems as a trust anchor. The second part of the article focuses on manual updating of the trust anchor and automatic installation by the operating system's update function. Automatic installation using DNSSEC itself (on the basis of RFC 5011) will be dealt with in a follow-up article, which will also provide a list of popular resolver software packages indicating whether each of them supports this feature.
Options
The best way to go about installing the new public key depends on a) the DNS server software being used, b) the operating system (OS) or the distribution that the software is running on, and c) when the new trust anchor is to be installed. Installation needs to be completed no later than 11 October 2017. After that date, it won't be possible to validate digital signatures on the basis of the old key pair. Then all internet domains will become unreachable for all users and applications that rely on the resolver in question.
There are three ways of installing the new public key as a trust anchor:
1. Manually (out-of-band)
The key is now available to download from IANA's website. Operators can therefore install it manually in their resolver configurations as a trust anchor.
2. Automatically by means of a software update
DNS software developers will include the new public key as a trust anchor in new versions of their products. DNS software provided with Linux and other OS distributions will be updated in the same way. So the new key will be automatically installed on the server along with other system updates.
3. Automatically on the basis of RFC 5011 (in-band)
RFC 5011 provides a mechanism for automatically installing new key material on an existing validating resolver. The system makes use of the existing DNSSEC infrastructure. The superordinate DNS server makes the new key available in the form of a DNSKEY record. A special SEP (Secure Entry Point) flag is set, so that the resolver knows that the key can be installed as a trust anchor. The authenticity of the new key material is guaranteed by the digital signature associated with the DNSKEY record, verifiable by reference to the existing trust anchor.
Consideration of the options
Although the developers of various resolver software packages have already indicated that their products will support RFC 5011, only options 1 and 2 are currently available. The new public key was not published in the root zone until 11 July, and for security reasons it has to be there for at least thirty days before it can be copied. In a follow-up article, we will provide a list of popular resolver software packages indicating whether each of them supports RFC 5011. Users of packages that support RFC 5011 have the option of waiting until 10 August, and then simply checking whether the new trust anchor has been installed successfully.
Users of other resolver software need to choose between waiting to see whether a new version of their software (which does support RFC 5011) is released, and installing the new trust anchor manually. We advise anyone who opts for the first of those strategies to set a 'deadline', after which they are no longer prepared to wait; if the deadline passes without the necessary software or OS update, another solution should be found.
Manual installation (option 1)
The first step in manual installation of the new trust anchor is to get the public KSKs from IANA's website. In addition to the XML file containing the keys (root-anchors.xml), on the same page you'll see a digital signature (root-anchors.p7s) and the ICANN certificates (icannbundle.pem). The mutual consistency of the three items can be verified as follows:
openssl smime -verify -in ./root-anchors.p7s -inform DER \
-content ./root-anchors.xml -CAfile ./icannbundle.pem
To view the certificate, use the following command (or simply open the file with Firefox):
openssl x509 -text -noout < ./icannbundle.pem
However, since all three files come from the same page and the ICANN certificate is self-signed, the check doesn't actually guarantee the authenticity of the XML file.
Authentication
Trust in the anchor for the DNSSEC root is based on its widespread publication by the internet authorities: the public key is 'well known'. In other words, if you come across the same key all over the internet, you can be confident that it's the real one. Before actually using the key as a trust anchor, it is therefore important to verify its authenticity via various sources.
Trust in the authenticity of the public KSKs obtained from IANA's website may be based first on the HTTPS connection to that website (which unfortunately doesn't yet support DANE). However, it is preferable to download and authenticate the keys using the specially developed DNSSEC Trust Anchor Fetcher. The fetcher consists of a Python script, which performs the following steps:
Key file download from the IANA website using HTTPS
Digital signature download from the IANA website using HTTPS
Signature validation using the built-in ICANN certificate
Key extraction from the XML file
Key validity period check
Verification that the keys match the public KSKs in the Google Public DNS and those in the root zone, as published on InterNIC.net
Recording of the keys in the form of DS and DNSKEY records
So, by reference to the digital signature, the procedure anchors the keys contained in the XML file fetched from the IANA website to the ICANN certificate built into the script (and thus to GitHub via HTTPS), to Google Public DNS (via DNS-over-HTTPS) and to the root zone file on InterNIC.net (via HTTPS).
Any system administrator can easily follow and verify the internal working of the script, which is based entirely on OpenSSL. The locations of the files on IANA's website are also specified in RFC 7958. Furthermore, the authenticity of this article on this web page is anchored by means of HTTPS, DNSSEC and DANE. Together, the various provisions should ensure that administrators, maintainers and developers incorporate the correct trust anchors into their systems.
Practicalities
This is how you make a local clone of the DNSSEC Trust Anchor Fetcher obtained directly from GitHub:
git clone https://github.com/iana-org/get-trust-anchor.git
Alternatively, a ZIP file can be downloaded:
https://github.com/iana-org/get-trust-anchor/archive/master.zip
The script is run using this command:
python get_trust_anchor.py
The following output will then be obtained:
[user@system get-trust-anchor]$ python ./get_trust_anchor.py
Validation of the signature over the file succeeded.
There were 2 KeyDigest elements in the trust anchor file.
Added the trust anchor 0 to the list:
{'Algorithm': '8',
'Digest': '49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5',
'DigestType': '2',
'KeyTag': '19036',
'validFrom': '2010-07-15T00:00:00+00:00',
'validUntil': ''}
Added the trust anchor 1 to the list:
{'Algorithm': '8',
'Digest': 'E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D',
'DigestType': '2',
'KeyTag': '20326',
'validFrom': '2017-02-02T00:00:00+00:00',
'validUntil': ''}
Trust anchor 0: there was no validUntil attribute, so the validity is OK.
Trust anchor 1: there was no validUntil attribute, so the validity is OK.
After the date validity checks, there are now 2 records.
Fetching via Google Public DNS...
Found KSK 257 3 8 'AwEAAagAIKlVZrp...ulqQxA+Uk1ihz0='.
Trust anchor 0 matched KSK 'AwEAAagAIKlVZrp...ulqQxA+Uk1ihz0='
There were 1 matched KSKs.
Writing out ksk-as-dnskey.txt.
The key tag for this KSK is 19036
Writing out ksk-as-ds.txt.
Deleting the temporary files.
As you can see, when this script was run only the old key (KSK-2010) could be validated via Google Public DNS. At that time, KSK-2017 had yet to be added to the root zone. From 11 July, however, it will be possible to validate both keys and the script will then write both to the files ksk-as-dnskey.txt and ksk-as-ds.txt.
Anyone considering using the above script in an automated update process needs to ask themselves whether the installation of trust anchors without human intervention – or, at least, prior human verification – is a good idea. The great danger is not that the wrong keys might be installed – that would be apparent soon enough – but that an additional trust anchor might be added. If you make the update manually, you know that there should currently be exactly two keys.
Automatic installation by means of a software update (option 2)
On some validating resolvers, the new public root KSK will already have been installed as a trust anchor as part of an automatic or user-initiated software update. That may even have happened without the operator being aware of it. Even before the new key was published in the root zone as a DNSKEY record, DNS software developers and OS distribution maintainers were able to add it to their systems. That's because it has been possible to install the key using the procedure described above since the key was first published in February.
The current status (as of 30 June) of the three most popular resolver software packages is described below with regard to the new public root KSK.
BIND named
BIND named, the most widely used DNS server, has supported the managed keys feature since version 9.7.0. The feature is enabled by the (default) configuration option 'dnssec-validation auto'. If the feature is enabled, on start-up the server fetches the current public KSKs, as published in the root zone, and installs them as trust anchors. That involves the server using the trust anchors built into the code and specified in the managed keys statements to initialise ('initial-key') the managed key database (in managed-keys.bind, or per view). However, the server uses the hard-coded trust anchors only if they are not overruled by an external bind keys file (default: bind.keys).
Because named performs the initialisation only when first started (if the managed key database is still empty), RFC 5011 will need to be followed for subsequent updates.
Trust anchors specified in a trusted keys statement are by definition static. The configuration option described was introduced when DNSSEC validation was first implemented in BIND version 9.6.2.
Conclusion: If you use BIND version 9.7 or above, it is best to replace an old configuration that has a trusted keys statement for the public root KSK with a newer configuration that uses the managed keys feature. If you are still using an installation based on version 9.6.x, you have no alternative but to manually add KSK-2017 to your existing configuration.
Unbound
With the Unbound validating resolver, the configuration options for the specification of trust anchors are similar to those in BIND. The 'auto-trust-anchor-file' option was introduced in version 1.4.0, at the same time as support for RFC 5011. The file containing the managed keys is specified as follows:
auto-trust-anchor-file: "/etc/unbound/root.key"
Initialisation is performed using the unbound-anchor tool:
unbound-anchor -a "/etc/unbound/root.key"
The tool fetches the public root KSKs, performs the checks specified in RFC 7958, and finally installs the new trust anchors in the relevant file.
The keys and ICANN certificates built into the code function as the basis (hints) for the bootstrap of the system. From version 1.6.1, Unbound also provides the KSK-2017 trust anchor as a standard component of the software. The built-in certificates can be overruled using the file '/etc/unbound/icannbundle.pem'.
If the 'unbound-anchor' command is incorporated into the start-up script for Unbound, initialisation can be performed in much the same way as with BIND. Subsequent updates will be made in accordance with RFC 5011, for which purpose the root zone is checked a few times a month (tracking).
Static trust anchors can be specified in the 'trust-anchor' file (blank by default), or in the configuration itself, using the 'trust-anchor' option.
Conclusion: If you are using Unbound version 1.4.0 or above, you can use the automatic update capability based on RFC 5011. If you have an earlier installation, you will need to add KSK-2017 manually as a static trust anchor.
PowerDNS Recursor
PowerDNS Recursor has supported DNSSEC validation only since version 4.0. The philosophy of this resolver's developers is that, wherever possible, the complexities should be hidden from the user (resolver operator) and that as much as possible should be automated. Where the trust anchors are concerned, that implies having the public root KSKs hard-coded into the software. Because RFC 5011 is not supported, the best way of getting KSK-2017 into the Recursor is to upgrade to version 4.0.5, which includes the new trust anchor.
If upgrading isn't an option, you can get KSK-2017 added to the Recursor using the Lua interface. You can establish whether the Lua feature is available using the following command:
pdns_recursor --version
The Lua command itself is then as follows:
addDS('.', "20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
The command can be added to the start-up sequence in the form of a script.
The new key can be added without restarting the resolver (so that the cache is not lost) by using this command:
rec_control add-ta . 20326 8 2 \
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
To ensure that the new trust anchor is still used after any subsequent resolver restart, you would also need to add the Lua script.
Finally, this command can be used to find out what trust anchors the Recursor is currently using:
rec_control get-tas
Windows DNS Server
Microsoft introduced an initial, limited version of DNSSEC as part of Windows Server 2008 (DNS Server) and Windows 7 (includes the DNS client, a stub resolver). According to Martin Vliem, National Security Officer at Microsoft Netherlands, DNS Server is used mainly in 'split DNS' configurations to facilitate Active Directory. For such internal zones, DNSSEC isn't an option, because they are always dynamic.
Vliem says that there are very few old configurations with DNSSEC validation, since validation has to be explicitly enabled on both the server and the client. Furthermore, the initial version of DNS Server supported only SHA-1, meaning that it cannot validate the root zone (signed with SHA-2); it can validate only SHA1-based islands of trust. Another significant consideration is that, for extra security, DNS Server also performs validation itself if the client does not request it.
From Windows Server 2012, DNS Server features a complete DNSSEC implementation, including support for RFC 5011. Therefore only operators of older systems need to check whether their servers perform DNSSEC validation. If so, the new KSK-2017 will need to be added to the system manually as a trust anchor. That involves adding a DNSKEY record to the file %windir%\System32\DNS\TrustAnchors.dns using the DNS Manager or the Dnscmd.exe tool. Trust anchors installed on a domain controller are saved in the forest directory partition of the Active Directory Domain Services (AD DS) and are automatically distributed to all domain controllers in the forest.
Installations may differ in practice
The information presented above about the various resolver software packages and their configurations is intended merely to explain the basic situation. In practice, an installation may differ considerably from those described, e.g. if the maintainer of an OS distribution has added KSK-2017 to their package 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. In that case, the best approach is to upgrade the configuration to the current software version.
Automatic installation of the new trust anchor on the basis of RFC 5011 will be considered in a follow-up article, as will testing to verify that everything is working properly.