In this article, we explain how you can check the availability of the new trust anchor.
Automated test environmentICANN has set up an automated test environment that validating resolver operators can use to check that the RFC 5011 update mechanism is working properly on their systems. The procedure involves first manually installing a trust anchor for a special subdomain. The public KSK for the subdomain is then rolled over, so that the complete update cycle is followed. For details of the update mechanism, see the earlier article about RFC 5011.
Each week, a new test cycle is started with a new domain. Detailed information about the current status of the relevant domain and how to check whether everything is working properly is available by subscribing to e-mail updates.
The ICANN test environment serves only to check the general performance of the RFC 5011 update mechanism. You can't use it specifically to establish whether the KSK-2017 trust anchor is present and working properly. Or, as ICANN themselves say in their 2017 KSK Rollover External Test Plan: "It allows operators of validating resolvers to test whether their systems are likely to work during the KSK rollover if they are using RFC 5011."
However, what an operator wants now, with just four weeks left before the actual rollover, is to know for sure that the public KSK-2017 really has been installed on the resolver as a trust anchor. Unfortunately, it isn't yet possible to actually validate a domain name using the new root KSK. That's because, in order to limit the size of the UDP packet and thus prevent fragmentation of the network packets, a single-signature rollover design has been adopted. Consequently, until the actual rollover on 11 October, the root ZSK won't be signed using the new KSK, meaning that no chain of trust whatsoever can be built for KSK-2017.
Check trust anchors
The RFC 5011 update mechanism is ultimately a means to an end, i.e. installation of the KSK-2017 trust anchor. So it's more important to check whether the end has been achieved than whether the means are functional. In the following paragraphs, therefore, we look at each of the most popular resolver software products in turn and explain how the current trust anchors can be shown.However, before checking the trust anchors, it's worth making sure that your resolver is actually validating. You can do
dig @ADRES dnssec-failed.org a +dnssec
If your resolver is validating, the response to that command will be the status message SERVFAIL, because, as the domain name indicates, the command deliberately involves a bogus DNSSEC chain of trust. A non-validating server won't check for a digital signature and will therefore return the status NOERROR.
From version 9.7.0, BIND named, the most widely used DNS server software, saves its trust anchors in the managed key database (in the managed-keys.bind file, or in View from version 9.8.0). From version 9.11.0, you can check out the contents using the following command:
rndc managed-keys status
In older versions, the script contrib/scripts/check5011.pl provides similar functionality.
If the KSK-2017 trust anchor, whose key ID is 20326, isn't listed (with the status 'trusted'), you'll need to refer to the detailed information about the root KSK rollover published by ISC (BIND named's developer).
The validating resolver software Unbound saves its trust anchors in the 'auto-trust-anchor-file' (/etc/unbound/root.key). That file should include the KSK-2017 trust anchor (key ID 20326), and its status should be 2/VALID.
The philosophy of the developers of PowerDNS Recursor 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. From version 4.0.5, the KSK-2017 (key ID 20326) is accordingly hard-coded. If you are using an older version, you'll need to add the new trust anchor using the Lua interface or the 'rec_control add-ta' command.
The following command can be used to find out what trust anchors the Recursor is currently using:
Knot DNS Resolver
The Dnsmasq server loads its trust anchors from the trust-anchors.conf file. From version 2.77, the new KSK-2017 trust anchor is supplied with the software in that file. Developer Simon Kelley says that versions older than 2.76 should no longer be used anyway, due to bugs in the validation element.
(See the CHANGELOG for version 2.69 for details of the implementation of DNSSEC validation in Dnsmasq.)
All Infoblox appliances require the manual installation of the new KSK-2017 trust anchor. Infoblox Nederland says users are being actively informed.
Windows DNS Server
DNSSEC wasn't fully implemented on the Windows platform until Windows Server 2012. The trust anchors for the Windows DNS Server are saved in the file %windir%System32DNSTrustAnchors.dns.
In the PowerShell, you can view the current trust anchors using the following command:
Get-DnsServerTrustAnchor -Name .
The TrustAnchorData delivered in response should include the new key (key ID 20326) and the TrustAnchorState should be Valid.
The verified availability of an active KSK-2017 trust anchor gives validating resolver operators the best chance of a smooth rollover on 11 October. Successful completion of the checks described above is therefore vital. As explained earlier, there is no way of actually validating a domain name on the basis of the new root KSK ahead of the rollover. The checks described are consequently both the least and the most that an operator can do before the big day.
If the checks reveal that the new KSK-2017 trust anchor isn't available/active on the resolver, we recommend referring back to our earlier articles on manual and automatic installation of the new trust anchor. Of course, there's also information in the software supplier's own documentation, and ICANN has published two hands-on articles [1, 1, 2].
NB: because of the hold-down period of at least thirty days, it's now too late to start an update procedure based on RFC 5011. Therefore, any validating resolver that doesn't yet have the KSK-2017 trust anchor installed now requires urgent manual installation.
Finally, it's worth pointing out that, if the new trust anchor doesn't work on 11 October, the ultimate fallback option is to temporarily disable DNSSEC validation until the underlying problem has been rectified.