Category: Root KSK Rollover

Oct 04

Are you ready? How to prepare for the DNSSEC Root KSK Rollover on October 11, 2018

skeleton key

Are you ready? Are your systems prepared so that DNS will keep functioning for your networks?  One week from today, on Thursday, October 11, 2018, at 16:00 UTC ICANN will change the cryptographic key that is at the center of the DNS security system – what we call DNSSEC. The current key has been in place since July 15, 2010. This is a long-planned replacement.

If everything goes fine, you should not notice and your systems will all work as normal. However, if your DNS resolvers are not ready to use the new key, your users may not be able to reach many websites!

This change of this central security key for DNS is known as the “Root Key Signing Key (KSK) Rollover”. It has been in discussion and planning since 2013. We’ve written many articles about it and spoken about it at many conferences, as have many others in the industry. ICANN has a page with many links and articles at:

But here we are, with only a few days left and you may be wondering – how can I know if my systems are ready?

The good news is that since the Root KSK Rollover was delayed 1 year, most all of the DNS resolver software has been shipping for quite some time with the new key. If you, or your DNS server administrators, have been keeping up with recent updates, you should be all set.

1. Test if you are doing DNSSEC validation

Before you do anything else, you should first check if you are doing DNSSEC validation on your network.  As noted in ICANN’s guidance document, go to a command-line / terminal / shell window and type:

dig @<IP of your DNS resolver> dnssec-failed.org a +dnssec

For example, using Google’s Public DNS Server, the command would be:

dig @8.8.8.8 dnssec-failed.org a +dnssec

If the response includes this text:

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

then you ARE doing DNSSEC validation and should read the rest of this article.

If the response instead includes:

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

… well, you are NOT doing DNSSEC validation. You can skip the rest of this article, go have a beverage, and not have to worry about the Root KSK Rollover on October 11.  However, you should also read up on DNSSEC and understand why you start validating to raise the level of security and trust on your network. (But, at this point, you might as well wait until October 12 to deploy it.)

If you are doing DNSSEC validation, read on. 

Two notes:

  • Unfortunately if you are not an administrator of your DNS resolvers, there are limited mechanisms to check if you have the new key. There are a couple of possibilities (see #2 and #3a below), but otherwise you will need to contact your DNS administrators / IT team and point them to this blog post and other resources.
  • In DNS / DNSSEC circles the root key is also referred to as a “trust anchor”.

2. Try the Sentinel KSK Test

For a small percentage of you reading this, you might be able to use the “sentinel test” that is based on an Internet draft that is in development. You can do so at either of these sites:

Right now there is only one DNS resolver (Unbound) that implements this sentinel test. Hopefully by the time we do the next Root KSK Rollover, some years from now, this will be more widely deployed so that regular users can see if they are protected.

However, for most of us, myself included, we need to go on to other methods…

3a. Check if your DNS resolvers have the new Root KSK installed – via various tools

There are several tests you may be able to perform on your system. ICANN has published a list at:

That document lists the steps for the following DNS resolvers:

  • BIND
  • Unbound
  • PowerDNS Recursor
  • Knot Resolver
  • Windows Server 2012RS and 2016
  • Akamai DNSi Cacheserve
  • Infoblox NIOS

For BIND users, ISC2 also provides a focused document: Root KSK Rollover in BIND.

3b. Check if your DNS resolvers have the new Root KSK installed – via specific files

If you have command-line access to your DNS servers, you can look in specific files to see if the new key is installed.  The current key (“KSK 2010”) has an ID of 19036. The new key has an ID of 20326. As Paul Wouters wrote in a Red Hat blog post today, these keys can be found in these locations in Red Hat Linux:

  • bind – see /etc/named.root.key
  • unbound / libunbound – see /var/lib/unbound/root.key
  • dnsmasq – see /usr/share/dnsmasq/trust-anchors.conf
  • knot-resolver – see /etc/knot-resolver/root.keys

Look in there for a record with an ID of 20326. If so, you are all set. If not, you need to figure out how to get the new key installed.

Note – these locations here are for Red Hat Linux. Other Linux distributions may use slightly different file locations – the point is that there should be a file somewhere on your system with these keys.

4. Have a backup plan in case there are problems

As Paul notes in his post today, it would be good to have a backup plan in case there are unexpected DNS problems on your network on October 11 and users are not able to resolve addresses via DNS. One suggestion is to temporarily change your systems to give out one of the various sets of “public” DNS servers that are operated by different companies. Some of these include:

IPv4 IPv6 Vendor
1.1.1.1 2606:4700:4700::1111 Cloudflare
8.8.8.8 2001:4860:4860::8888 Google DNS
9.9.9.9 2620:fe::fe Quad9
64.6.64.6 2620:74:1b::1:1 Verisign

You can switch to one of these resolvers while you sort out the issues with your own systems. Then, once you have your systems correctly configured, you can switch back so that the DNSSEC validation is happening as close to your users as possible (thereby minimizing the potential areas of the network where an attacker could inject malicious DNS traffic).

5. Plan to be around on 11 October 2018 at 16:00 UTC

Finally, don’t schedule a day off on October 11th – you might want to be around and able to monitor your DNS activity on that day.  This Root KSK Rollover has been in the works for many years now. It should be a “non-event” in that it will be “just another day on the Internet”. But many of us will be watching whatever statistics we can. And you’ll probably find status updates using the #KeyRoll hashtag on Twitter and other social networks.

The end result of all of this will be the demonstration that we can safely and securely change the cryptographic key at the center of DNS – which allows us to continue improving the level of security and trust we can have in this vital part of the public core of the Internet!

Image credit: Lindsey Turner on Flickr. CC BY 2.0

P.S. This is NOT what the “Root key” looks like!

Acknowledgements:  Thanks to Ed Lewis, Paul Hoffman, Paul Wouters, Victoria Risk, Tony Finch, Bert Hubert, Benno Overeinder, Hugo Salgado-Hernández, Carlos Martinez and other members of the dnssec-coord discussion list for the discussion that informed this post.

The post Are you ready? How to prepare for the DNSSEC Root KSK Rollover on October 11, 2018 appeared first on Internet Society.

Sep 28

ICANN Postpones DNSSEC Root KSK Rollover – October 11 will NOT be the big day

People involved with DNS security no longer have to be focused on October 11. News broke yesterday that ICANN has decided to postpone the Root KSK Rollover to an unspecified future date.
To be clear:

The Root KSK Rollover will NOT happen on October 11, 2017.

ICANN’s announcement states the the KSK rollover is being delayed…

…because some recently obtained data shows that a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover. The availability of this new data is due to a very recent DNS protocol feature that adds the ability for a resolver to report back to the root servers which keys it has configured.

Getting More Information

Discussion on the public DNSSEC-coord mailing list indicates more info may be available in a talk Duane Wessels is giving at the DNS-OARC meeting tomorrow (Friday, September 29). The abstract of his session is:

A Look at RFC 8145 Trust Anchor Signaling for the 2017 KSK Rollover

RFC 8145 (“Signaling Trust Anchor Knowledge”) was published in April 2017. This RFC describes how recursive name servers can signal, to authoritative servers, the trust anchors that they have configured for Domain Name System Security Extensions (DNSSEC) validation. Shortly after its publication, both Unbound and BIND implemented the specification. As organizations begin to deploy the new software versions, some of this “key tag data” is now appearing in queries to the root name servers.

This is useful data for Key Signing Key (KSK) rollovers, and especially for the root. Since the feature is very new, the number of recursive name servers providing data is not as significant as one might like for the upcoming root KSK rollover. Even so, it will be interesting to look at the data. By examining this data we can understand whether or not the technique works and hopefully inspire further adoption in advance of future KSK rollovers.

If you, like me, will not be in San Jose for this session, there will be a webcast / live stream. The link should be available tomorrow morning on the DNS-OARC event page. Or you can follow the #oarc27 hashtag or @dnsoarc onTwitter.

Per the OARC 27 timetable, Duane’s talk begins at 9:40am PDT (UTC-7). (Side note: for those involved with DNS, there are many other excellent sessions on the timetable!)

Apparently whatever data ICANN received through this research convinced them that not enough ISPs were ready to go with the new KSK and so a postponement was necessary.

Understandable caution

I do understand why ICANN would step back and delay the KSK roll. If there are significant sections of the Internet that will experience issues with resolving DNSSEC-signed domains on October 11, it is prudent to wait to assess the data and potentially reach out to affected ISPs and other network operators. Particularly when, as we noted in our State of DNSSEC Deployment 2016 report last year, the number of domains signed with DNSSEC continues to grow around the world.

I look forward to working with ICANN and the rest of the DNSSEC community to set a new date. As I wrote (along with my colleague Andrei Robachevsky) in our comments back in April 2013, we believe that the Root KSK should be rolled soon – and rolled often – so that we gain operational experience and make Root KSK rollovers just a standard part of operations.  (Note: our CITO Olaf Kolkman submitted similar comments, although at the time he was with NLnet Labs.)

Updating the DNS infrastructure is hard

The challenge ICANN faces is that updating the global DNS infrastructure is hard to do. The reality is that DNS resolvers and servers are massively DE-centralized and controlled by millions of individual people. You probably have one or more DNS resolvers in your home in your WiFi router and other devices.

The success of DNS is that generally it “just works” – and so IT teams often set up DNS servers and then don’t pay much attention to them. At a talk I gave yesterday to about 180 security professionals at the ISC2 Security Congress in Austin, TX, I asked how many people had updated the software on their DNS resolvers within the past year – only a few hands were raised.

All of the latest versions of the major DNS resolvers support the new Root KSK. Recent versions all generally support the automated rollover mechanism (RFC 5011). But… people need to upgrade.

And in the example of a home WiFi router, the vendor typically needs to upgrade the software, then the service provider has to push that out to devices… which can all take a while.

A group of us looking to expand the use of elliptic curve cryptography in DNSSEC wrote an Internet Draft recording our observations on deploying new crypto algorithms. Updating the root KSK as a trust anchor faces a similar set of issues – although a bit easier because the focus is primarily on all the DNS resolvers performing DNSSEC validation.

The critical point is – upgrading the global DNS infrastructure can take some time. ICANN and members and of the DNSSEC community (including us here at the Internet Society) have been working on this for several years now, but clearly the new data indicates there is still work to do.

Next Steps

The good news is that companies now have more time to ensure that their systems will work with the new key.  The new Root KSK is published in the global DNS, so that step has at least been done. More information is available on ICANN’s site:

https://www.icann.org/kskroll

I would recommend two specific pages:

The time to do this is NOW to be ready for the Root KSK Roll when it does happen.

For more information about DNSSEC in general, please see our Deploy360 DNSSEC page.

Image credit: Lindsey Turner on Flickr. CC BY 2.0

P.S. And no, that is NOT what the “Root key” looks like!

The post ICANN Postpones DNSSEC Root KSK Rollover – October 11 will NOT be the big day appeared first on Internet Society.

Oct 27

Watch Live TODAY – DNSSEC Root KSK Ceremony at 17:00 UTC

DNSSEC Key Ceremony 25

Today a critical part of DNS security – DNSSEC – will receive a major update, and you can watch it all live at starting at 17:00 UTC (1:00pm US EDT – local time) streaming out of ICANN’s data center in Virginia:

https://www.iana.org/dnssec/ceremonies/27

Olaf Kolkman, our CITO, will be in attendance as a “Crypto Officer” (key holder). Olaf wrote a post with info about the 25th key ceremony back in May 2016 and shared some of his photos.

The important step today is that this key ceremony will involve the creation of a new Key Signing Key (KSK) for the root of DNS. This begins what will be a year-long process of “rolling over” the cryptographic key at the heart of the DNSSEC system. ICANN has a page dedicated to the “Root KSK Rollover” explaining the details – and this “at-a-glance” PDF provides the key facts and dates.

This is a great step in making DNSSEC even more secure.

If you’re interested, ICANN posts the “script” that will be used to go through today’s key ceremony. All of the key ceremonies are streamed live and archived for later viewing.

If you want to learn more about DNSSEC in general, please visit our Start Here page to find resources to help!

Image credit – Olaf Kolkman on Flickr. Used with permission.

Sep 01

New RFC 7958 – DNSSEC Trust Anchor Publication for the Root Zone

RFC 7958 text

How can you trust the root of the “global chain of trust” that is used in DNSSEC? How can you be sure as you are validating DNSSEC signatures that this global chain works?

To provide this chain of validation, DNSSEC relies on what is called a “trust anchor”. When you check the signature for DNS records for “internetsociety.org”, for instance, you go through a process along the lines of this (a simplified version):

  1. Your validating recursive resolver gets the DNS records (such as “A” or “AAAA”) for “INTERNETSOCIETY.ORG” along with the DNSSEC signature in a RRSIG record and the public key used for the signing in a DNSKEY record.
  2. It then retrieves the DS record for “INTERNETSOCIETY.ORG” from .ORG to verify that this is the correct DNSKEY.  It also retrieves a RRSIG record for the DS record and the DNSKEY record from .ORG.
  3. Next it retrieves the DS record for “.ORG” from the root of DNS, along with the associated RRSIG for the DS record and the DNSKEY for the root.
  4. HERE IS THE CHALLENGE – How does your recursive resolver know that the DNSKEY it retrieved for the root of DNS is the correct one?

This is where there is a need for a “trust anchor” that the recursive resolver can trust to know that this is indeed the correct DNSKEY it should be using.

The DNSSEC protocol can be used with any trust anchor, but in practice we all use the DNSSEC trust anchors published by IANA (with ICANN doing the actual publishing as part of their contract to perform the IANA functions).

A new informational (non-standard) RFC 7958 out this week explains the formats IANA uses to publish the root key trust anchors and how those trust anchors can be retrieved.  It also outlines additional steps that can be taken during the retrieval to ensure the trust anchors aren’t modified during the retrieval.

In 2017 we will see a change in the Root Key Signing Key (KSK) in 2017, which will mean a change in the root trust anchor. This RFC 7958 is a good reference to have out there so that everyone can understand exactly how to retrieve and use the trust anchors at the heart of DNSSEC.

Please do read this new RFC and share it widely with anyone involved in developing applications or services that perform DNS resolution and validation.

And if you know very little about DNSSEC but want to learn more, please visit our Start Here page to find resources to help you get started!

Oct 05

5 Hours Left To Submit Comments on ICANN Design Team Review of Plan for DNS Root Zone KSK Change

ICANN.jpgDo you have any comments on the findings of the ICANN Design Team regarding the changing of the root zone key-signing key (KSK) for DNSSEC?  If so, you have about five hours left to submit your comments as the comment period ends at 23:59 UTC today, 5 October 2015. You can read the Design Team report and submit your own comments at:

https://www.icann.org/public-comments/root-ksk-2015-08-06-en

The comment period has been open since August 6, 2015, and the word has been distributed through multiple online mailing lists and other forums in the time since.  To date there have only been a few comments, although I’m seeing several (including my own) coming in today:

http://forum.icann.org/lists/comments-root-ksk-06aug15/index.html

You may recall that ICANN announced the members of this design team back in February 2015 and this was after a comprehensive public comment period back in 2013.  Here are some links that can provide some context:

As you will see in my own response, I am generally pleased with the findings of the Design Team but have a few points I wish to add.

NOW IS THE TIME TO SUBMIT YOUR COMMENTS… you have about five hours left!

P.S. And if you just want to learn what DNSSEC is all about, please visit our Start Here page to learn more!

Feb 06

ICANN Announces DNSSEC Root KSK Rollover Design Team

ICANN.jpgAfter soliciting statements of interest back in December, ICANN announced this week the people who had been selected for the DNSSEC Root Key Signing Key (KSK) Rollover Design Team. They are:

  • Joe Abley, Snake Hill Labs/DyN, CA
  • Jaap Akkerhuis, NLNetLabs, NL
  • John Dickinson, Sinodun Internet Technologies, UK
  • Geoff Huston, APNIC, AU
  • Ondrej Sury, CZ.NIC, CZ
  • Paul Wouters, No Hats/Red Hat, NL
  • Yoshiro Yoneya, JPRS, JP

We’ve written before about how important we believe the rollover of the Root KSK of DNSSEC is, and we are pleased to see this next step in the process.  All of the people selected have been extremely involved in the DNS / DNSSEC community for many years and have contributed in many ways to the ongoing deployment of DNSSEC.

We look forward to hearing the next steps taken by this team to move forward on rolling the Root KSK.  I suspect there will be some discussion at ICANN 52 next week in Singapore, but I also expect much more to happen after that event in the months ahead.

P.S. If you want to get started with DNSSEC, please visit our Start Here page to begin!

Oct 16

Root DNSSEC KSK Rollover Workshop Streaming Live Today From ICANN 51

ICANN 51 Los Angeles

Today (Oct 16, 2014) from 9:00 am to 12 noon US Pacific, a special public workshop about implications of a “rollover” of the “Root Key Signing Key (KSK)” that serves as the ultimate “trust anchor” for DNSSEC will be streamed live from ICANN 51 in Los Angeles. Information about how to participate remotely can be found at:

http://la51.icann.org/en/schedule/thu-dnssec-key-rollover

(Note: the times on that page have not yet been updated.  The workshop will be from 09:00-12:00, although it may extend later if discussions continue.  It will definitely conclude by no later than 13;30 PDT.)

ICANN Chief Technology Officer (CTO) David Conrad has organized this public discussion about issues related to changing the Root KSK.  This will be a chance to publicly discuss what we collectively see as potential issues when the Root KSK is rolled or changed and what we need to do about those issues.  This is a critically important topic and so it is great to see ICANN holding this session.

The public workshop is aimed to be a discussion forum to collect guidance from a wide range of people.  An adhoc program committee was established of Joe Abley, Duane Wessels, Roy Arends, Jakob Schlyter, David Conrad and myself.  I was asked to act as a moderator to ensure that the flow moves appropriately and that all get to contribute.  The proposed agenda is:

1. INTRODUCTION

A brief level setting of why the workshop has been called, where we are at in the process (ICANN public consultation in early 2013, SSAC report, ICANN Board resolution in Nov 2013), and what we hope to do in the workshop.  (See my recent “Background Information” post for links for more info.)

2. HOW a Root KSK Rollover might occur

We would like to discuss how an automated (RFC5011) would occur as well as non-5011 roll options and options for a staggered roll.  Joe Abley will discuss a couple of relevant Internet Drafts.

3. WHAT a Root KSK Rollover might involve

We would like to discuss what changes might be made during a Root KSK Rollover. Specifically two points:

  a. ALGORITHM CHANGE – Geoff Huston will give a presentation about potential impacts of a change of the algorithm. (Geoff also presented this information about the DNS-OARC meeting this past weekend.)

  b. Length of KSK – There has been some discussion about changing the length of ZSKs and KSKs and moving to longer key sizes.  We would like a discussion around this idea and the potential impacts.

4. IMPLICATIONS

Discussion of additional implications beyond those discussed earlier.  For instance, issues around response sizes.

5. POTENTIAL TIMELINE (unanchored)

We would like to discuss what a potential timeline might look like for the entire process.  The intent is NOT to establish a fixed date but rather to establish what a timeline might look like for the full process to take place.

6. NEXT STEPS

We want to spend the end of the session identifying specific steps and actions that will occur coming out of this workshop.

If you are interested in this topic, you can join ICANN’s “ksk-rollover” mailing list and read the archives.

And if you want to get started NOW with deploying DNSSEC, why not visit our Start Here page to find resources tailored for your type of organization?