Skip to main content
Resources

Checking the Current Trust Anchors in DNS Validating Resolvers

This page is intended for administrators of DNS resolvers (sometimes called "recursive resolvers") who want to be sure they are using the latest trust anchor for DNSSEC validation. If you run such a resolver and are not sure whether or not your resolver will be ready for the KSK rollover, you can use the instructions here to be sure you have the latest trust anchor.

There is a companion document that describes how to update to the latest trust anchors; you can find it here. More information about the KSK rollover can be found here.

The information here is only needed if your DNS resolver is validating DNSSEC. ICANN encourages DNSSEC validation wherever it is appropriate, but if you are not yet validating DNSSEC, you do not need the instructions here.

To test whether or not the resolver you operate is doing DNSSEC validation, you can use the special domain "dnssec-failed.org" that is operated as a public service by Comcast. This special domain will cause validating resolvers to purposely fail to give an answer. Give the following command at a shell command line:

dig @ADDRESS dnssec-failed.org a +dnssec

In that command, replace the string ADDRESS with the IPv4 or IPv6 address of the resolver you operate.

If the response includes the following:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

then the resolver is doing DNSSEC validation. (The status indication of SERVFAIL here indicates that the validation failed, which means that the validation is in fact happening.)

If instead the response includes the following:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

the the resolver is not doing DNSSEC validation.

The rest of this page lists various resolver implementations and the instructions needed to check the trust anchors on them.


BIND

BIND versions 9.9, 9.10, and 9.11 support DNSSEC validation using automatic RFC 5011 updating. The latest sub-versions of these versions come with KSK2017 as part of the trust anchors.

First check that DNSSEC validation is set in your configuration file. You should see a line in the options section that says either dnssec-validation auto; or dnssec-validation yes;. If your configuration shows dnssec-validation yes;, you must change it to dnssec-validation auto; and restart your server before taking the steps below.

To generate a file that contains the trust anchors in use, given the command

rndc secroots

That command creates a file called named.secroots in the same directory that BIND's other files are created. That file should contain two lines, one of which says ./RSASHA256/20326 and the other which says ./RSASHA256/19036. If it does not have both those keys, you should update your trust anchors as described here.

ISC, the creators of BIND, have additional information about DNSSEC trust anchors for BIND at https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html.


Unbound

Look in the root.key file in Unbound's configuration directory, which is usually /etc/unbound. It should have DNSKEY records in it, one that has the text id = 20326 and another whose that has the text id = 19036; both records should also say ;;state=2 [ VALID ]. If the file does not have both those keys, or if either of the keys do not have a state that says ;;state=2 [ VALID ], you should update your trust anchors as described here.


PowerDNS Recursor

PowerDNS Recursor version 4 supports DNSSEC validation, but does not yet support DNSSEC validation using automatic RFC 5011 updating. This means that for PowerDNS Recursor, you need to get a new set of trust anchors every time the trust anchors change. Version 4.0.5 and later of PowerDNS Recursor come with KSK2017 as part of the installed trust anchors.

In the command-line interface, give the command:

rec_control get-tas

It should a line that includes the text . 20326 and another that includes the text . 19036. If it does not have both those keys, you should update your trust anchors as described here.


Knot Resolver

Knot Resolver supports DNSSEC validation using automatic RFC 5011 updating in all versions.

Look in the root.keys file in Knot Resolver's configuration directory (which changes based on distribution). It should have two lines in it, one that includes the text 0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DB and another that includes the text 0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5. If it does not have both those keys, you should update your trust anchors as described here.


Windows Server 2012R2 and 2016

Windows Server, both 2012R2 and 2016, supports DNSSEC validation using automatic RFC 5011. The commands below user Windows PowerShell.

To check the contents of the trust anchors, use:

Get-DnsServerTrustAnchor -Name . 

You should see:

TrustAnchorName   TrustAnchorType   TrustAnchorState   TrustAnchorData
---------------   ---------------   ----------------   ---------------
.                 DNSKEY            Valid              [19036][DnsSec][RsaSha256][AwEAAagAIKlVZrpC6Ia7...
.                 DNSKEY            Valid              [20326][DnsSec][RsaSha256][AwEAAaz/tAm8yTn4Mfeh...

The key tags are displayed under TrustAnchorData. For the root trust anchor, you should see two key tags: 19036 and 20326. Both trust anchors should have their state marked as "Valid". If it does not have both those keys, you should update your trust anchors as described here.

To view all current trust points that are active on the server, use:

Get-DnsServerTrustPoint 

This will show:

TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017  8:37:02 PM   9/12/2017 8:37:02 PM 

Nominum Cacheserve 7

Nominum Cacheserve 7 (versions equal to or greater than 7.1.2.3, 7.2.0.3, 7.2.1.2) supports DNSSEC validation using RFC5011 managed keys. Although the capability also exists in older versions, it should not be used because there was a problem with the rollover code. To check if Nominum Cacheserve is actually validating run the following command:

nom-tell cacheserve resolver.mget fields='(trusted-keys managed-keys-state)' 

If there are any trusted-keys or managed-keys-state fields in the output, Cacheserve is doing DNSSEC validation and you need to make sure that the correct keys are use. In the managed-keys-state for the root ('.') you should see keyid with the value of 19036 and 20326 both with the state being valid and the has-validated field is set to True. For trusted keys you have to compare the actual key material. To check that, or to fix the keys if they are not as described, see the description here.


Infoblox NIOS

Infobox NIOS supports DNSSEC validation, but does not yet support DNSSEC validation using automatic RFC 5011 updating. This means that for Infoblox NIOS, you need to configure a new set of trust anchors every time the trust anchors change.

The steps to check the current trust anchors in NIOS are:

  1. Log in to the NIOS GUI
  2. Navigate to Data Management → DNS
  3. Click on "Grid DNS Properties" from the toolbar
  4. Toggle "Advanced Mode" on
  5. Select the "DNSSEC" tab
  6. Scroll down to "Trust Anchors"
  7. All configured trust anchors will appear in the "Trust Anchors" table. Look for an entry with "." in the "Zone" column and a check in the "Secure Entry Point" column. (If there is no such trust anchor, no root zone key-signing key is configured.) Mouse over the value in the "Public Key" column to see the complete value.

If checking from the member level:

  1. Log in to the NIOS GUI
  2. Navigate to Data Management → DNS → Members/Servers
  3. Select the DNS server
  4. Click on "Edit"
  5. Toggle "Advanced Mode" on
  6. Select "DNSSEC"
  7. Scroll down to "Trust Anchors"
  8. All configured trust anchors will appear in the "Trust Anchors" table. Look for an entry with "." in the "Zone" column and a check in the "Secure Entry Point" column. (If there is no such trust anchor, no root zone key-signing key is configured.) Mouse over the value in the "Public Key" column to see the complete value.

To distinguish between the old root root key-signing key and the new one, the old root zone key-signing key will appear as:

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

The new (current) root zone key-signing key will appear as:

AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOL
AJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3Eg
VLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWe
L3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555Kr
UB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."