Support for secure transfer of signed domains now complete
PowerDNS also supports the publication of external key material
PowerDNS also supports the publication of external key material
Although DNSSEC was formally introduced to the Netherlands in 2012, the transfer of secure domains remained a problem for a long time. 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.
A transfer protocol that made that possible was devised several years ago by Antoin Verschuren, Technical Advisor at SIDN, and has since been standardised by the IETF.
However, the new transfer procedure required the receiving registrar and the releasing registrar to exchange key material: something that SIDN's registry interface didn't support at the time. Last year, a new EPP command was therefore developed: key relay.
Now that PowerDNS — the most widely used DNS server for signed domains — officially supports the publication of external key material, the chain is complete. Signed domains can now be transferred between registrars securely and automatically. In the summer, Monshouwer became the first registrar to implement and use the entire transfer protocol.
The direct-dnskey option has recently become a fully operational feature of PowerDNS. Although the switch was introduced to the DNS server software a year ago (in version 3.2), it was labelled 'experimental' until last month's release of version 3.3.1. PowerDNS therefore now formally supports the secure IETF transfer protocol for DNSSEC-enabled domains.
"When it was published, I took a close look at the Internet Draft for this protocol," recounts Peter van Dijk, Programmer and Support Technician at Netherlabs, the lead developer and supporter of the PowerDNS software. "It was quickly apparent that support for the transfer protocol would only require a minor addition to our software. When the 'direct-dnskey' option is enabled, imported DNSKEY records are included in the database in the context of zone signing and publication. So key material obtained from another registrar can be included in the zone, which is a requirement for setting up a secure transfer."
Although the secure transfer of a signed domain is a somewhat cumbersome process, its complexity has very few implications for the PowerDNS software. The DNS server obtains its information from the supporting database — usually a MySQL database — and uses that to generate its zones. How the information gets into the database is irrelevant to PowerDNS. Operators populate their databases using separate scripts, which undertake procedures such as interacting with the registry on the basis of EPP (the Extensible Provisioning Protocol). The database therefore forms an interface between the DNS server and the back end that delivers the zone information.
"The complexity of the transfer process is procedural; the communication and publication of the key material are not technically complex." That's the assessment of Kees Monshouwer, founder and proprietor of the internet company that bears his name. Monshouwer has adopted a PHP EPP library originally developed by internet service provider Mijndomein and has extended it to support DNSSEC and key relay. That enabled the company to undertake the first successful secure transfer of a signed domain last summer.
"Adding support for the transfer protocol was a few days' work. It involved chopping the transfer process into a number of steps. However, the arrival of the EPP 'key relay' command has made the exchange of key material between registrars very straightforward. The receiving registrar signs the new zone and sends the public keys to the releasing registrar via the EPP interface. The releasing registrar is then notified that external key material is available. After that, it's just a question of fetching the material, doing a few checks, signing the keys and publishing them."
"For PowerDNS, those last two steps involve nothing more than completing a field in the supporting database," says Monshouwer. "As soon as a new record is written, the DNS server swings into action. To do the same thing with BIND named, you would first have to write, sign and publish a zone file. BIND does have a database back end, but remains very file-focused."
"In fact, a secure transfer is three-quarters the same as a key rollover, but carried out by two registrars instead of one. Introduction of the EPP 'key relay' command means that we now have an electronic portal, through which the two registrars can easily exchange key material. The one thing missing is feedback: ideally, you'd like to receive a message via the same interface saying that the key material has been received safely and when it will be published. As it is, you just have to wait and see what happens, knowing that your key material might never get published. So your customer might be left hanging on for another two days, during which time you can't tell them what the score is."
"SIDN could also do more to promote implementation of the transfer protocol by registrars. Problems with the transfer of secure domains represent a major cause of corrupted domains. You might have an implementation framework in the form of pseudo-code or a detailed flow diagram. Another alternative would be a reference implementation. At the moment, most registrars write their own scripts, few of which get published. Because not much validation is going on, people tend to overlook just how complicated a comprehensive DNSSEC implementation actually is."