On March 7, I moved my domain away from the hosting provider where it had originally been registered.

The domain was first registered on December 29, 2016. At the time, I had suddenly decided to rebuild my blog, chose a hosting provider, and bought both the domain and hosting from the same place in one go. A few minutes later, the blog was online. In 2017, I renewed both the hosting and the domain through 2020.

This transfer was not a spur-of-the-moment decision. I compared several large domestic and overseas registrars, taking into account past experience with domain registration as well as pricing, service quality, domain management tools, privacy protection, registrar policies, and a few other practical factors. In the end, I narrowed the choice down to NameSilo and Porkbun.

For the .com domain I use, the annual renewal price was $8.99 at NameSilo and $8.56 at Porkbun. Converted to RMB, the difference was only a little over two yuan. Price was not really the deciding factor. I chose Porkbun because NameSilo’s domain management operations felt relatively cumbersome, and its website text was small and dense enough to make the interface uncomfortable to read.

On the morning of March 1, 2019, a little after 9 a.m., I submitted a support ticket to request the transfer authorization code. About 40 minutes later, the code was sent to me. I then went to Porkbun, started the transfer, and paid $8.56, which came to 59.37 RMB.

After that, I followed the transfer instructions. About an hour later, I received an automated email from the original registrar. The message was in English and roughly said that the system had received a notice that I wanted to transfer the domain to 1861 — Porkbun’s IANA registrar ID. If I wanted to cancel the transfer, I could click the link before March 6. If I did intend to transfer out, I did not need to do anything. If there was no response from me by March 6, the transfer would proceed to the next step.

One important part of the transfer process is email verification through the address listed in the domain’s WHOIS information. In theory, that means WHOIS privacy must be disabled. But in my case, I could not find any way to turn off WHOIS privacy in the hosting provider’s control panel. There simply was no such menu.

Yet Porkbun still managed to send the verification email to me, and its website even showed which email address the message had been sent to. When I checked WHOIS, I found that the privacy protection was already gone and the domain information had become fully public. I can only guess that the registrar had an interface that automatically disabled WHOIS privacy once a transfer-out request was detected.

There were two main reasons I decided to move the domain away from the hosting provider.

First, the price there was not competitive. Renewal cost 80 RMB for one year, 140 RMB for two years, and 210 RMB for three years, with the same pattern continuing from there. WHOIS privacy protection cost another 20 RMB per year and had to be selected. From the first-year purchase through the later renewal to 2020, I had spent a total of 365 RMB.

Second, the provider’s domain registration service was actually resold through PDR, a company that specializes in offering domain reseller services to hosting providers. Recently, the domain control panel in the provider’s account backend appeared to have a connection issue with the interface. Apart from renewals, other domain management operations could not connect to the PDR service. The error shown was:

CURL Error: 35 - OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to httpapi.com:443 (IP: & ×××.×××.×××.×××)

If I had needed to perform any operation other than renewing the domain, that would have been a problem. Fortunately, I had already been using third-party DNS, so during the outage I did not need to manage DNS records through the account backend.

The reason I moved DNS away earlier was also a bit frustrating. Starting in the afternoon of September 2, 2017, my blog was inaccessible for more than 20 consecutive days. For other reasons, I did not deal with it immediately. On September 30, 2017, I contacted the hosting provider’s support team. They told me that since September 2, their authoritative DNS had been attacked, and suggested that I migrate DNS elsewhere, recommending either dns.com or dnspod.cn.

I changed the DNS to the free service at dns.com, and the site came back online soon afterward. On October 1, 2017, I moved the records again to a dnspod.cn account I had registered back in 2011. Later, on September 16, 2018, I switched to Hurricane Electric Free DNS Management.

Because of that switch, my blog was not affected by the large-scale outage of the domestic version of DNSPod on the evening of November 9, 2018. Some of my other domains, however, were still using the domestic DNSPod service and were affected: they were either resolved to 8.8.8.8 or ended up with no IP address found.

The domain transfer to Porkbun was completed at 05:30 UTC on March 7, 2019, which was 13:30 Beijing time. At 13:45, the domain appeared in Porkbun’s backend system, and new WHOIS data began being served from Porkbun’s database. At 14:00, Porkbun sent the transfer success email. At 15:04, the original hosting provider emailed me to say that the transfer to 1861 had been completed, and that from then on I would no longer be able to manage the domain through their control panel.

On March 9, 2019, the domain management issue on the hosting provider’s side returned to normal. From the time I discovered the fault until it was fixed, it lasted about one month.

Not long ago, Cloudflare launched its domain registration service. At the moment, it only supports transfers, not new registrations, though new domain purchases are expected to be available at some point in the future. Cloudflare charges only the wholesale cost, which is how I learned that the cost price for a .com domain is $8.03 per year.

There is one condition for transferring a domain to Cloudflare: the domain must use Cloudflare’s DNS. I did not choose Cloudflare not because of Cloudflare itself, but because Cloudflare’s DNS servers have long been a focus of attention. I encountered that in 2011, and again in September 2017. There is not much to be done about that; Cloudflare just happens to be caught in the middle.

As for the other problems I have run into over the years while buying and managing domains, those are worth discussing separately.