11th October 2017, DNSSEC key rollover of the root zone, be ready the key is here!


On the 27th September, ICANN announced the postponement for the KSK rollover. More information can be found here.

written by Yves Bovard

No, this is not a kind of secret message nor a new ice-cream. On 11th October 2017 the root zone will be signed with a new key. Ladies and gentlemen, update your DNS resolver. As of July 11th, the new key is published in the root zone and your resolver should start updating its trust anchors automatically!

Nowadays security is a key point in our Internet life. When we think at it, words such as automatic updates, SSL, SSH, HTTPS or FTPS come immediately in mind; we protect our servers with the most up-to-date patches (ok, we hope so…) we protect communication to our webservers with SSL certificates, for some data we also encrypt the filesystem and for some services, we use tunnelling. But what about DNS? How can we be sure that our current correspondent is the real one and not a hacker? The answer is: use DNSSEC dude!

Let me first explain the resolving process (the cache mechanism is omitted here to keep it as simple as possible). Thanks to the hierarchical data structure, the resolvers only need to know the uppermost node to have access to the whole tree. After entering “www.switch.ch” in our browser, the computer forwards this query to a DNS resolver. From here begins a chain. The first step is to get the addresses of the root name servers. There is no need to configure them, they are built in the software. As every zone (‘.’ is a zone as well as ch. and switch.ch.) knows its childs (‘ch.’ is a child of ‘.’ and ‘switch.ch.’ is a child of ‘ch.’ as well), our resolver just has to ask the parent zone for the addresses of the servers in charge of the child zone. This chain ends when the current servers knows the answer of the question (in our case them managing ‘switch.ch.’).

Nothing in this process asks of any kind of proof of identity. That is what DNSSEC does: it asks for a signature of each answer, which are matched to the public key in the current zone, which are then matched to its hash located on the parent zone. These verifications continue until we reach the root zone, which is signed by a key that has to be configured as trust anchor in resolvers. To be able to solve the whole chain, a DNS resolver has to know two things: addresses of the root zones and the hash of the key used by the root zone.

Since July 2010 the root zone is signed with DNSSEC. As with every password or identity card, it should be renewed from time to time. This will happen for the first time on 11th October 2017. That implies a bad and a good news. First of all, the bad one. If the resolvers do not include the new key (id 20326), they will not be able to validate every domains from the 11th October. Now the good one: since we update our software regularly, no action is needed; most manufacturers already included the new key in the lastest version or the resolvers should automatically retrieve the new key in the next 30 days using RFC5011. Here are three popular software:

  • BIND 9: versions after 9.11.1, 9.10.5 and 9.9.10 have both keys in the ‘bind.keys’ file (normally located at /var/bind/bind.keys or /etc/named.root.key). If the option “dnssec-validation” is setted to “auto”, the software will update the keys during the next few days. Here is an output of a ready to rollover root key file:
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=";
};
  • Unbound: on most Linux and UNIX distributions,  unbound executes ‘unbound-anchors’ during startup which updates the trust anchors. To verify if the new key is installed, the ‘auto-trust-anchor-file’ can be read:
# cat /var/lib/unbound/root.key
...
. 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=1 [ ADDPEND ] ;;count=21 ;;lastchange=1499778888 ;;Tue Jul 11 15:14:48 2017
. 172800 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1499778888 ;;Tue Jul 11 15:14:48 2017
  • PowerDNS Recursor includes the new key as of version 4.0.5. To see it, use “rec_control get-tas”:
# rec_control get-tas 
Configured Trust Anchors: 
. 
  19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
  20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
...

 

If your traffic lights are green, you can sleep well. If not, updating your software is a good starting point. In most cases, the key 20326 will be included. If your resolver does not validate queries (you can check it with https://rootcanary.org/test.html ; red flags means that your resolver does not validate queries), use this opportunity to activate DNSSEC on your resolver. On most products, it is just an option to turn on. With one simple action, you can add a stone in securing the whole stack! Having a validating resolver is also a good first step in the process of securing your domains with DNSSEC. More than just validating the answers, using DNSSEC to sign zones offers some useful technologies like securely publishing SSH fingerprints in the DNS (no, checking the fingerprint and type ‘yes’ will not be needed anymore during the first SSH connection on a server), PGP public keys or TLS certificates with DANE.

If you want to have more informations about this Root Zone KSK rollover, ICANN publish descriptions, news, overviews and timeline on the website https://www.icann.org/resources/pages/ksk-rollover

One thought on “11th October 2017, DNSSEC key rollover of the root zone, be ready the key is here!”

  1. Pingback: Review of DomainX 2017 in Delhi, India - Mother./Blog

Comments are closed.