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.
Some of the examples below use Key Tags for the KSKs. (Key Tags are defined in RFC 4034.) The key tag for for KSK2010 is 19036, and the Key Tag for KSK2017 is 20326.
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:
- 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
- In your configuration file, be sure that the
options
section has a line that saysdnssec-validation auto;
. - 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:
-
Update the
bind.keys
file to include the new trust anchor. Thebind.keys
file should be stored in the same directory that BIND's other files are created. Alternatively, if your named.conf file has amanaged-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:
-
Remove the current trust anchors with:
rm root.key
-
Get the latest version of trust anchors with:
unbound-anchor
-
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:
-
Update to Unbound version 1.6.5 or later.
-
Remove the current trust anchors with:
rm root.key
-
Get the latest version of trust anchors with:
unbound-anchor
-
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:
- 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 ]
. - 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:
- 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.
- 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:
-
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
-
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")
-
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.
-
In the configuration file, make sure there is a line that says:
trust_anchors.file = 'root.keys'
-
If that file does not contain a line that contains
19036
and20326
, stop the server using whatever method you normally use, delete theroot.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.
Akamai DNSi Cacheserve
Akamai Cacheserve (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:
-
The easiest way to get to the latest DNSSEC root key is to use managed keys and update to Akamai DNSi 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:
- See the information at https://support.nominum.com/view-article/965 or contact Akamai 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:
- Log in to the NIOS GUI
- Navigate to Data Management → DNS
- Click on "Grid DNS Properties" from the toolbar
- Toggle "Advanced Mode" on
- Select the "DNSSEC" tab
- Scroll down to "Trust Anchors"
- Click on the "Add" button and enter the key's details. The zone is "." and the algorithm is "RSA/SHA-256(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:
- Log in to the NIOS GUI
- Navigate to Data Management → DNS → Members/Servers
- Select the DNS server
- Click on "Edit"
- Toggle "Advanced Mode" on
- Select "DNSSEC"
- Scroll down to "Trust Anchors"
- Click on the "Add" button and enter the key's details. The zone is "." and the algorithm is "RSA/SHA-256(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=