Just four weeks until the root KSK rollover: time to check your DNSSEC trust anchors!

Validating resolvers that support RFC 5011 should by now have installed and activated the new public root KSK as a trust anchor. If you're still using software that doesn't support RFC 5011 and you haven't yet manually installed the new trust anchor, it's important that you do it soon. From 11 October, all internet domains will become unreachable for anyone relying on a resolver that doesn't have the new trust anchor installed.

In this article, we explain how you can check the availability of the new trust anchor.

Automated test environment

ICANN 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.

Limited testing

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.


BIND named

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.

PowerDNS Recursor

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:

rec_control get-tas

Knot DNS Resolver

The trust anchors of the Knot DNS Resolver are saved in the 'trust_anchors.file' (root.keys). That file should include the following two key strings:

0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DB 0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5


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.

Probleemloze roll-over

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.


  • Friday 20 April 2018


    Your brand as a domain name extension? New opportunity planned!


    Application window opens in 2021

    Read more
  • Monday 23 July 2018

    Internet security

    Beware: stand-ins and holiday temps targeted by cybercrooks


    Summer holiday period now in full swing

    Read more
  • Wednesday 30 January 2019

    About SIDN

    Developers want to clean up DNS software code


    "Nearly a quarter of the code is now for workarounds and corner cases"

    Read more


Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.