insight 

We’ve just released a position paper on signing the root. There is quite a lot to this but I thought I would attempt to summarise the paper for those of you who don’t want to read the full seven pages.

Next steps for DNSSEC

This is a key point in the development of DNSSEC. With the imminent approval of NSEC3, us and many other registries will be in a position to sign their zones, because NSEC3 deals with the issues of zone file enumeration and excessive resource usage.

DNSSEC is not a well known technology with high demand for it, but it never will be. It is a critical layer in developing a secure Internet and must be implemented by TLDs to enable the next layer to be secure. A good example of the next layer is DKIM, the anti-spoofing technology the uses the DNS for publishing data.

What is special about DNSSEC?

We should remember that DNSSEC is just error-checking technology, so that when you receive some DNS data you can be sure that it has come from who you think it has and that is has not been tampered with en-route.

However the fact that DNSSEC uses signatures to do this, gets some people a bit confused. So we need to be clear on the fundamental statement that DNSSEC makes. First we have to make a distinction between delegation data, which is the data that TLDs publish, and ordinary DNS data. All we are interested in is what it means when someone signs delegation data.

It is our view that when delegation data is signed by a registry all that it is saying is:

We are using this signature to securely transmit to you the data that has been supplied to us, but we make no warranty as to its content.

This power of this statement is that it can work at all levels of the DNS hierarchy where there is delegation, not just for TLDs.

The challenges of implementing DNSSEC

Obviously (or perhaps not to some) we need the root signed, but more on that later.

For registries there are a number of technical process that need to be developed:

• Secure key management.
• Signing updates to the zone as they are made. Or generating a signed zone if you don’t use dynamic updates.
• Automated re-signing. All signature will expire over time, even if the delegation data does not change. So a process is needed to automatically re-sign the data to maintain up to date signatures.
• Managing resource usage. We know that full DNSSEC implementation gives a tenfold increase in a zone but with opt-in we can introduce it gradually.

Who should sign the root and how?

To start we need to explain the current structure of how the root is managed. IANA manage the database of TLDs and delegation data under contract to the US DoC. They then send their data to the Root Zone Maintainer (RZM), currently Verisign, again under a sort of contract with the US DoC. THe RZM then update the root zone and push the changes to the other root zone operators.

We now get to our critical point on signing the root:

We contend that there should be a single DNSSEC trust anchor and that this should be at the same point as the single authoritative list of TLDs. This can only be achieved by signing the root. Indeed, the standard has been designed on this assumption. Anything else would be splitting the root.

Some people have gone ahead and introduced DNSSEC without the root being signed, but this does not scale and is not really the way forward.

We propose a process for signing this, where IANA generates the keys and sends them to the RZM who then uses them to sign the zones. This reflects the current political arrangements for managing the root and the current split in responsibility. Of course if these arrangements change then this process should change, but DNSSEC should not be a lever to change these arrangements - there are already plenty of other levers.

Is there an alternative to signing the root?

The short answer is no. One alternative being proposed is DLV, a non-standard way of using an alternate trust anchor, or set of alternate trust anchors.

For a start this is not a technical standard and its current form could introduce a degree of instability to the Internet that is not currently present.

But more importantly, using DLV multiplies the issues that we currently have about who controls the root. With DLV who is to decide which keys to recognise for which TLD?

Summary

So to summarise the summary:

• There should be a single root that combines the authoritative list of TLDs and the start of the DNSSEC
  chain of trust for those TLDs.
• Sign the root as soon as possible, with IANA responsible for creating and managing keys and the RZM
  responsible for adding signatures to the root zone data.
• Deal with oversight issues for the IANA function as a whole, through the ongoing process towards
  enhanced cooperation arising out of the Tunis Agenda.
• Avoid DLV.