Sion Lloyd
DNS “just works” ™ – so much so that most internet users are unaware of its existence, or at least are not conscious of it operating underneath every transaction. This is no accident; it is down to a number of factors, including a very robust and resilient protocol and a number of organisations working very hard to make sure that DNS remains out of the spotlight.
Of course, when DNS stops working, it soon makes the news, even when the underlying technical issues may be misunderstood.
With the volume of people and organisations reliant on the internet – and so also reliant on the DNS – it is understandable that those running the infrastructure are conservative by nature. Playing against this conservatism is the rapidly changing environment they find themselves in, and we have seen that tension play out this week. We will talk here about what has happened (or actually what will not happen yet) without going into too many of the technical details.
DNS has a security layer whereby DNS responses can be authenticated via cryptographic signatures; these signatures are created with cryptographic keys. This whole system relies on having a key that you can find and validate to act as a ‘trust anchor’, with everything else being chained back to it. This is the ‘root zone key-signing key’, commonly known as the root key.
Due to concerns about keys being compromised through brute-force it is common practice to change these keys on occasion, a procedure known as rolling the key. This procedure has been carried out on many, if not most, of the keys in use today with one notable exception – the root key. As the trust anchor of the whole system, the mechanism for rolling has to be carefully carried out; any errors could result in large parts of the internet going dark.
There is a protocol for this, defined in a document known as RFC5011. It describes a method of using the current trusted key to impart trust in the new key, allowing the rolling of the root key. This protocol has been initiated with the publication of a new key; the next step, removal of the old key was due to happen in October. The issue is that while ICANN, the root operator, can do everything correctly according to this document, it isn’t possible to tell if other relevant DNS infrastructure has done its part. The new key was published in July of this year, but how do we know if clients updated their trust anchors to include this key?
A recent document, RFC8145, introduced a mechanism to signal back to the root which trust anchors have been configured by a DNS operator. While not exhaustive (only more recent deployments have this capability), some data is better than none, and at a recent DNS meeting, Duane Wessels of Verisign presented their analysis.
The main issue is the number of clients who do not appear to have the new root key configured as a trust anchor. For these clients, removing the current root key would result in the failure of authentication. This number is seen in their dataset to be around 100 individual clients (out of around 1,400 clients with RFC8145 capability) or 7%. Their data also show that this number seems to be reasonably stable with time. Remembering that this sample set is biased from the start by being limited to newer clients, it is reasonable to assume that the true number is higher.
This is the reason that ICANN recently announced a postponement to the removal of the current root key; the risk is just too great. As ICANN president and CEO Göran Marby said in their announcement:
“The security, stability and resiliency of the domain name system is our core mission. We would rather proceed cautiously and reasonably, than continue with the roll on the announced date of 11 October. It would be irresponsible to proceed with the roll after we have identified these new issues that could adversely affect its success and could adversely affect the ability of a significant number of end users.”
This has to be the correct thing to do in the face of such uncertainty.
While no date has been set for the next step of the key rollover, the extra time for further data collection, analysis and reaching out to the community will hopefully result in an event which, like so much in DNS, goes largely unnoticed.