SIDN acts as intermediary in the transfer of DNSSEC-enabled domains

Standard method

Antoin Verschuren, Technical Advisor at SIDN and inventor of the IETF method, has come up with a list of reasons why the solution will become the standard:

• Very little is required of the releasing DNS operator, and the actions that are required can be automated.

• The receiving registrar is in control.

• With the ICANN method, the zone information has to be copied in its entirety, e.g. via AXFR. The necessary data could be transferred via other channels, e.g. the registrant. However, regardless of the channel used, the ICANN method involves more information being transferred between the registrars than the IETF method does.

• The ICANN method doesn't allow the signatures to expire while the transfer is in progress. However, in practice, it is difficult to set things up in a way that ensures the signatures won't expire during transfer. All you can do is wait and see whether things go wrong.

• With the ICANN method, the releasing operator has to set a very short TTL for the NS set prior to the transfer in order to minimise caching. That results in more look-ups and therefore more DNS traffic. Furthermore, short TTLs make the DNS vulnerable to trivial errors.

• No matter how short the TTL is, the domain name will briefly be 'bogus' while the NS set is being changed over. Its bogus status will last for at least a few seconds. That may not be disastrous, but it does mean that the ICANN method doesn't formally meet the requirement that security should be effective throughout the transfer.

Guiding principles

"When developing our solution for the problem of secure transfers, we focused mainly on what would be workable for registrars and the entire chain of registry, registrar, reseller, registrant and DNS operator," says Verschuren. "My experience as a registrar for various registries meant that I had a good idea of what would and wouldn't work."

Key assumptions:

• There is no direct and secure communication channel that all operators can access; SIDN should therefore act as an intermediary.

• Private keys must not be exchanged.

• The amount of information exchanged should be minimised.

• Everything should be automatable in order to secure the cooperation of releasing operators.

• Crucially, a registrant's freedom to choose a registrar must be preserved so that market forces remain effective. The receiving registrar or receiving operator must remain in control of the process, therefore. It mustn't be possible to hold a domain name hostage, which would have been a risk if the releasing operator's active cooperation had been required.

• SIDN wishes to facilitate a process, rather than impose one. Registrars can then decide whether they want to use that process.

Relay system for ZSKs

The DRS (Domain Registration System) could be modified to support a new ZSK being made available to the old registrar," says Sebastiaan Assink, Operations Manager at internet hosting provider Oxilion. "The old registrar could then add the ZSK to the zone, or forward it to the DNS operator, if that's a different organisation."

"SIDN has now started work on the development of just such a relay system for ZSKs. We'll facilitate secure transfers by adapting the existing secure administrative channel to enable keys to be exchanged between DNS operators and registrars," says Verschuren. "We won't do anything with the ZSKs ourselves, we'll just make sure that they reach the releasing registrars via our secure registration environment."

"In a secure transfer, the receiving registrar has to give the new ZSK to the releasing DNS operator. To make that possible, we plan to add a new command to the EPP (Extensible Provisioning Protocol). The procedure will involve a series of further steps -- transfer, add DNSKEY, NS change, and delete old DNSKEY -- with a pause between each step and the next. The registrar will be able to define the length of each pause or look it up using the DNS. SIDN won't be imposing any timers of its own."

"The releasing registrar will get the forwarded ZSK and associated domain name from SIDN via the EPP queue, and will know that the transfer has been authorised with a transfer token. If the releasing registrar isn't also the releasing operator, the registrar will pass the key on to the operator. The only thing that the releasing operator has to do is add the ZSK to the zone and re-sign it."

Kidnapping

One issue that will need attention is the possibility of the releasing DNS operator setting an excessive TTL for the DNSKEY. "The releasing operator decides the validity period of its DNSKEY records,"explains Assink. "The transfer procedure will involve the old operator adding the new ZSK to the zone and signing it with their own KSK. However, you don't want to change the name servers for a domain until you're sure that the old DNSKEY set has expired and everyone can use the new ZSK for validation. If the old operator were to set a very long TTL (say, a week), you would have to wait a week between adding the new DS record and changing the name servers."

"At a certain stage in the transfer process, the waiting time will indeed depend on the TTL of a record in the releasing operator's zone," confirms Verschuren. "That TTL has to expire before the next step in the process is taken. There's a possibility of an uncooperative operator setting a high TTL value in order to delay the transfer. That would clearly frustrate the process. You can think of it as a sort of kidnapping, which is something want to prevent, of course."

"SIDN already applies a set of technical requirements, which include acceptable values for crucial TTLs. The intention is to add acceptable TTLs for DNSKEY records. We've previously been fairly relaxed about monitoring compliance with the technical requirements, so you do occasionally come across DNS operators who use anomalous TTLs. However, any operator that continues to do that will encounter problems sooner or later. Their market reputation will be damaged and they'll lose customers. We therefore think it's important that the receiving registrar is in control of the transfer process. So the receiving registrar will always have the option of suggesting to the registrant that they fall back on the insecure transfer procedure, or use another method, and pinning the blame on the releasing operator."

Internet Draft

Verschuren has already transferred the domain sidnlabs.nl to demonstrate that secure transfers are possible and what's involved. "For the transfer, I simulated only the secure administrative channel. Any existing registrar can do the same thing. However, few important domains are currently being transferred, so all transfers are insecure, or result in validation errors."

"With .nl domains, it's currently normal for DNSSEC security to be suspended prior to transfer," Assink adds. "For the moment, that's acceptable; it's better than a period of bogus status (DNSSEC error status). That won't be the case for long, however. An insecure transfer won't be an option; all transferred domains will have to remain secure. However, with some TLD operators (including the operator of Sweden's .se domain), transfers using the IETF method aren't even possible. In those cases, the advice is actually to suspend security."

With regard to the IETF method itself, Verschuren points out that the current Internet Draft has now expired and is awaiting republication. "It currently has 'individual submission' status. In other words, formal approval hasn't yet been requested from the IETF DNSOP Working Group, so it isn't yet clear whether the document will be supported by the group. That's going to happen soon, though. The intention is to request 'Informational' status, implying that the document won't become a protocol standard. It'll simply be a description of how you should go about a secure transfer. A new internet protocol isn't required for that. Everything is already in place, it's just a question of the sequence in which things should be done."

Active role

"Following the Lunch & Learn meeting where the transfer issue was discussed at length, there were no new developments within the registrar community or the Technical Committee," Assink points out. "After an internal evaluation, we've revised our processes here at Oxilion, so that we're compatible with the IETF method for both the .nl domain and other TLDs. The transfer of secure domains will also be on the Technical Committee agenda."

Assink also expects the Dutch operator to play an active role. "Internationally, a lot of eyes are on SIDN where DNSSEC is concerned. SIDN has to take advantage of that, by seeking interaction with the registrars and DNS operators in the field, and by sharing the feedback obtained with other registries. It would also be really good if they could organise and facilitate training and workshops for registrars and operators."

Assink's wishes in that regard look like being fulfilled: at the annual Contact Day on Thursday 29 November in Utrecht, Verschuren will be making a presentation on the transfer of DNSSEC-enabled domains.