Implementing security requires attention to detail. Integrating security services with applications where neither the security service nor the application consider their counterpart in their design sometimes make plain that a fundamental change in existing practices is needed. Existing “standard” registrar business practices require revision before the benefits of the secure infrastructure foundation DNSSEC offers can be realized.

This article is the third in my series on the state of DNSSEC deployment. Part One was an overall look at where the Internet community stands on deployment and adoption of DNSSEC. Part Two detailed a functionality gap that exists when a domain name owner uses a third-party to host their DNS services. In this article, I focus on a long-standing business practice in the domain name business that holds back effective DNSSEC deployment.

Typically, when a gTLD domain owner wants to transfer the existing registration of a domain name from one registrar to another, they must follow this process:

1. The domain owner requests the transfer at the new registrar.
2. The new registrar requests the transfer via the registry on behalf of the domain owner.
3. The old registrar receives the transfer request.
4. The old registrar may act on the transfer request.
5. If the old registrar does not acknowledge the transfer request to the new registrar within 5 days then the registry will automatically approve the transfer request at the end of the 5-day period.

The details and policies governing this process are variously defined in technical standards and ICANN policies. The specific policy of interest here is the ICANN Policy on Transfer of Registrations between Registrars, which defines the requirements and obligations of the New Registrar (Gaining Registrar), the Old Registrar (Registrar of Record), and the registry during a transfer. This policy does not specify any DNS requirements.

During Step 4, the common business practices for the Registrar of Record are to first, remove the domain name from the DNS, and second, not decline the transfer request. The effect of removing the domain name from the DNS is that attempts to access services and applications (e.g., a web site) that use the domain name will eventually fail as DNS time-to-live (TTL) values expire in DNS caches. Many registrars implement a 1-day TTL, while many DNS service providers implement a much shorter TTL (e.g., 300 seconds). In the case of a 1-day TTL, the domain name will not resolve on the Internet for approximately 4 days, after which the new registrar will become the registrar of record and would be able to restore DNS services.

In pre-DNSSEC days this technical issue would resolve itself relatively benignly. However, post-DNSSEC, if the domain name in question is DNSSEC signed, the failure of the domain name to DNS resolve (and hence, validate) results in a security incident. The previously benign “site not found” becomes a scary “you don’t want to go there” message, potentially damaging the credibility and brand of the domain name owner.

As most CircleID readers already know, the 5-day period exists as a buffer to give the old registrar the opportunity to address improper registration transfer requests. Unfortunately, dropping a signed domain name from the DNS effectively punishes the domain name owner for requesting a transfer.

The solution for this issue is better cooperation and collaboration between the old and new registrars. Registrars need to prioritize the continuity of secure service to end customers even during the 5-day transfer period. Registrars will be on both ends of transfers—gaining and losing. An old registrar that cooperates to ensure that a domain name continues to resolve securely throughout a transfer period is more likely to receive the same cooperation when they are the new registrar in the next domain name transfer.

There are two steps required to close this security hole. As I discussed in my second article, registrars need to support the import of key information. First, the Registrar of Record must import the new key information from the Gaining Registrar, submit it to the registry, and insert it into its own authoritative server for the domain name’s zone. Second, the Registrar of Record must continue to offer DNS services for the domain name after the transfer is complete for at least twice the time of the longest TTL for any record in the zone of the domain name or any record associated with the domain name (e.g., glue records). This requirement is based on the behavior of existing resolvers in the wild and will be the subject of a future blog post.

The current business practices around this transfer policy require urgent coordination amongst registrars so that effective DNSSEC deployment can happen without an impact to the end-user or the domain name owner.