EPP 'key relay': a structural solution for the DNSSEC transfer problem

Although DNSSEC was formally introduced to the Netherlands eighteen months ago, the transfer of secure domains has remained a problem. After all, when transferring a signed domain, the registrant will normally want to know that the domain will remain secure, not only after the new registrar takes control, but also while the transfer is in progress.

Exchange of key material

To make that possible, two problems had to be resolved. First, it was necessary to have a protocol for data exchange down a line of actors. In the most complex situation, the chain involves no fewer than six links: from the registrant to the old service provider and old registrar, and on to the registry (SIDN), and then back from the registry to the new registrar and new service provider, and finally to the registrant. In some, the DNS operator will even be a separate operator from the service provider. What's more, the various interactions must be carefully synchronised because DNS records and key material have precisely defined validity periods.

The second problem was the communication of key material. For the transferred domain to remain secure throughout the process, the new ZSK needs to be signed by the old operator and added to the old zone information before the transfer begins. However, until recently, there was no channel for communication between registrars that could be used for that purpose.

Break-point

Until now, the transfer of a domain has consequently been a security break-point. For example, hosting service provider Mijndomein operates a precautionary policy of automatically deleting the DNSKEY information lodged with SIDN whenever a customer requests a transfer token. If the domain isn't transferred within two weeks, a new key is generated and DNSSEC re-enabled.

The policy is designed to ensure that a new registrar that doesn't support DNSSEC can't leave the old key material with SIDN. That is a real danger, given that the default setting is for key material to remain intact in the event of a transfer. Furthermore, once the transfer has gone through, the old registrar cannot rectify the situation.

Supportive ISPs

Despite the efforts of SIDN and registrars such as Mijndomein, the number of 'secure' domains corrupted by old key material has risen to nearly 4 per cent over the last year. As a result, supportive ISPs that provide DNSSEC validation for their customers are having to deal with support requests from customers who can't reach the domains in question.

Last spring, that led T-Mobile to switch from hard validation to fault-permissive validation (val-permissive mode as it is known in Unbound, one of the most widely used validating resolvers). So validation errors are still detected, but no longer lead to the domain names in question being blocked.

In recent months, SIDN has consequently also devoted a lot of attention to this problem. The policy of calling the registrars responsible for most validation errors in the .nl domain is bearing fruit. According to Michiel Henneke, SIDN's Marketing Manager, the number of errors is now coming down.

EPP 'key relay'

This summer, a structural solution for the transfer of DNSSEC-enabled domains became available. SIDN's EPP (Extensible Provisioning Protocol) interface has been extended to support a new 'key relay' command, meaning that a domain can now be transferred without interrupting its secure status. What's more, the transaction can be fully automated. Registrars and software providers can incorporate the new functionality into their own dashboards and interfaces, and thus make it available to their own users.

"Here at SIDN, we've devised a new EPP command,"says Antoin Verschuren, Technical Advisor and inventor of both the IETF transfer protocol and the associated 'key relay' command. "Using the new command, key material can be transferred from one operator to another via the registrars. The practical outcome is that operators and registrars can now transfer domains without interrupting the security,"

"The new operator sends its key material to the registry. The registry sends the material to the existing registrar and operator, so that the existing operator can add it to its zone files. In other words, all that's now required is a single extra step before the transfer process. In effect, the new operator says to the old registrar: 'We plan to transfer this domain securely. Here is our key. Add it to zone, then we'll complete the process securely."

Standardisation

Formal standardisation of the 'key relay' command is currently in progress. The standardisation process involves publishing the protocol in an IETF RFC document. If, like us, you are a strong advocate of DNSSEC and want the market to embrace this DNS security standard, you have to be prepared to invest, asserts Verschuren. The problems surrounding secure transfer were holding back adoption, so we got together with a number of other registries and registrars to come up with a solution. We're now in the midst of an IETF standardisation process. The feedback so far has been entirely positive; people at the IETF like the idea. So we're expecting other registries to start using this extension. Our colleagues at DNS Belgium have now told us that they plan to implement EPP 'key relay' in 2014. So it'll be easy for registrars to register various domains in the same way.

Getting down to work

The implementation of 'key relay' has removed a significant obstacle to further DNSSEC adoption. "We were still being told that some people were reluctant to embrace DNSSEC," says Verschuren. "They weren't sure whether it was a good idea to secure their domains, because they were worried it would get in the way of future transfers. With the arrival of 'key relay', that problem has been removed. So we hope to see further migration to DNSSEC in the period ahead."

The new functionality is already available via SIDN's EPP interface. Registrars can therefore already implement 'key relay' in their own systems and try out the automated transfer protocol.