Skip to main content
Resources

Updating of DNS Validating Resolvers with the Latest Trust Anchor

This page is intended for administrators of DNS resolvers (sometimes called "recursive resolvers"). The information here is useful if either:

  • operators of those resolvers discover that they do not have the new KSK installed
  • those resolvers are giving errors for all DNS requests after the KSK rollover

These instructions will likely lead to using the latest trust anchor for DNSSEC validation.

There is a companion document that describes how to check if you are using the latest trust anchors; you can find it here. More information about the KSK rollover can be found 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 update 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 you have dnssec-validation set to auto, you do not need to update your software or configuration. You simply need to restart your software, using whatever command you normally use to stop and start BIND; this will bring in the latest trust anchors for dnssec-validation auto.

If your configuration shows dnssec-validation yes;, you must change it to dnssec-validation auto; and restart your server before taking the steps below.

If you can update your software:

  1. Update to the latest sub-version of BIND 9.9, BIND 9.10, or BIND 9.11 using whatever method you used to install the software. If you are running BIND 9.8, it is no longer supported software, and you need to update to BIND 9.9 or later. You want a sub-version of at least:
    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1
  2. In your configuration file, be sure that the options section has a line that says dnssec-validation auto;.
  3. Stop the old version of BIND and start the new version, using whatever command you normally use to stop and start BIND.

If you cannot update your software:

  1. Update the bind.keys file to include the new trust anchor. The bind.keys file should be stored in the same directory that BIND's other files are created. Alternatively, if your named.conf file has a managed-keys section that lists the trust anchors, you can update that section. The revised file or configuration section should contain the following:

    managed-keys {
    	. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    			FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    			bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    			X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    			W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    			Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    			QxA+Uk1ihz0=";
    
    	. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    			+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    			ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    			0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    			oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    			RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    			R1AkUTV74bU=";
    };
    

If the configuration has dnssec-validation set to auto, the contents of the bind.keys file will be combined with the the contents of the managed-keys block in the configuration. More information about this can be found at https://www.isc.org/downloads/bind/bind-keys/.

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

However, all Unbound versions before 1.6.5 have a limitation that prevent them from accepting the new trust anchor if the version is first started 30 days or later before the rollover.

If you are running Unbound version 1.6.5 or later:

  1. Remove the current trust anchors with:

    rm root.key
    
  2. Get the latest version of trust anchors with:

    unbound-anchor
    
  3. Restart Unbound so that it reloads the new configuration, using whatever command you normally use to start Unbound.

If you are running Unbound version 1.6.4 or or earlier, and can update your software:

  1. Update to Unbound version 1.6.5 or later.

  2. Remove the current trust anchors with:

    rm root.key
    
  3. Get the latest version of trust anchors with:

    unbound-anchor
    
  4. Restart the new version of Unbound so that it reloads the new configuration, using whatever command you normally use to start Unbound.

If you are running Unbound version 1.6.4 or or earlier, and one of keys in the root.key file is not listed as [ VALID ], and you cannot update your software:

  1. See the page at https://www.unbound.net/root-11sep-11oct.html for information on how to get a new root.key file from NLnet Labs with both keys set to [ VALID ].
  2. Restart Unbound so that it reloads the new configuration, using whatever command you normally use to start Unbound.

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.

If you can update your software:

  1. Update to the latest sub-version of PowerDNS Recursor using whatever method you used to install the software. Be sure that the version retrieved is 4.0.5 or later.
  2. Quit from the current version of PowerDNS Recursor and start the new one, using whatever method you normally use to stop and start the server.

If you cannot update your software:

  1. If you do not already have a lua-config-file line in your main PowerDNS configuration, you must add it. The line points to a file that contains additional PowerDNS configuration. This line might look like:

    lua-config-file=/etc/pdns/luaconf.txt
    
  2. In the file pointed to by the lua-config-file line, add the following two lines:

    addDS('.', "19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")
    addDS('.', "20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
    
  3. Restart PowerDNS Recursor, using whatever method you normally use to stop and start the server.


Knot Resolver

Knot Resolver supports DNSSEC validation using automatic RFC 5011 updating in all versions. To get the latest version of the trust anchors, you can delete your current version of the file with the keys and start Knot Resolver again. Therefore, you do not need to update your version of Knot Resolver; you simply need to get the latest trust anchors and restart Knot Resolver.

  1. In the configuration file, make sure there is a line that says:

    trust_anchors.file = 'root.keys'
    
  2. If that file does not contain a line that contains 19036 and 20326, stop the server using whatever method you normally use, delete the root.keys file, and start the server again. This will cause Knot Resolver to recreate the file with the latest trust anchors from IANA.


Windows Server 2012R2 and 2016

Windows Server, both 2012R2 and 2016, supports DNSSEC validation using automatic RFC 5011. To get the latest version of the trust anchors, you can update your current version of the file and restart Windows Server. The commands below user Windows PowerShell.

Trust anchors normally update automatically. To check the refresh time of a trust anchor, use:

Get-DnsServerTrustPoint

It will show:

TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017 7:45:03 PM    9/12/2017 7:45:03 PM

The times given are UTC. If the trust anchor is not refreshing properly, you can replace it with:

Add-DnsServerTrustAnchor -Root

After adding the trust anchor, you should see an updated LastActiveRefreshTime in the output of the Get-DnsServerTrustPoint command.

Note: If Add-DnsServerTrustAnchor -Root fails, make sure DNSSEC is enabled on the server. Use the three commands:

$a = Get-DnsServerSetting -All
$a.EnableDnsSec = 1
$a | Set-DnsServerSetting

You can verify that RootTrustAnchorsURL is pointing to https://data.iana.org/root-anchors/root-anchors.xml with the command:

(Get-DnsServerSetting -All).RootTrustAnchorsURL

If the Add-DnsServerTrustAnchor -Root command still does not work, then a firewall might be blocking transport. This can happen in some highly secure environments. To add the DS trust anchor manually, you need to know the digest, algorithm, and keytag. To add a DNSKEY trust anchor, you need the public DNSKEY (Base64Data). Alternatively you can import the trust anchor if you have access to the keyset (for a DNSKEY anchor) or DSSET (for a DS anchor) file. The digest, algorithm (digest type) and keytag for the root trust anchor can be viewed at https://data.iana.org/root-anchors/root-anchors.xml .

The following commands demonstrate manual addition of a DS trust anchor for the root zone.

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType SHA256 -KeyTag 19036 -ComputerName localhost -PassThru

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D -DigestType SHA256 -KeyTag 20326 -ComputerName localhost -PassThru

It is not necessary to restart the DNS service after updating trust anchors. However you might wish to clear the DNS server cache with the command:

Clear-DnsServerCache -Force

More information from Microsoft can be found at https://technet.microsoft.com/en-us/itpro/powershell/windows/dnsserver/add-dnsservertrustanchor.


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.

If you can update your software:

  1. The easiest way to get to the latest DNSSEC root key is to use managed keys and update to Cacheserve version:

    • 7.1.2.3
    • 7.2.0.3
    • 7.2.1.2

    or a later version on the respective trains, which have the new root key already built in and working.

If you cannot update your software:

  1. See the information at https://support.nominum.com/view-article/965 or contact Nominum at https://support.nominum.com/.

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 add the new root zone key-signing key as a Trust Anchor 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. Click on the "Add" button and enter the key's details. The zone is "." and the algorithm is "RSA/SHA-256(8)".
  8. Paste the key in the "Public Key" column. The public key is:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=
    

If adding 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. Click on the "Add" button and enter the key's details. The zone is "." and the algorithm is "RSA/SHA-256(8)".
  9. Paste the key in the "Public Key" column. The public key is:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=
    
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."