UPDATE:  The registry’s domain management interface and web-based Whois service are both back online this morning.  The latter has a different appearance and some statuses are displayed in the Czech language.

Our speculation is that the CZNIC’s FRED registry solution has been implemented to some extent, both due to the Czech text and the fact that there has been a workshop for NIC VE staff in which FRED participated (see here). 

 

The lack of reliable electricity in Venezuela has made it impossible for that country’s ccTLD registry to offer domain name services.

In the face of a humanitarian crisis, domain names are not at the top of anybody’s mind.  With that caveat aside, we wanted to address the elevated volume of questions about .ve with an article summarizing the current situation.

Let’s start with a bit of context:

For the past three years, requesting a service for a .ve domain has become increasingly-dependent on human work.  During this period, the registry first removed the option of credit card payment, instead requiring that the payer upload proof that money had been deposited into their account at a local bank.  Next, the completion of forms to register/modify domains no longer triggered an immediate Whois update and the user had to wait for a registry employee to manually update the registry database.

Registry employees are knowledgable and performed the aforementioned tasks well, so it was jarring when service levels dropped earlier this year.  Requests took days or weeks to be processed, if they were processed at all.  An early hypothesis was that the experienced registry employees had either left, or were not currently working their normal schedule.

While never discarded all together, this initial hypothesis began to give way to another.  Once e-mails to registry contacts started bouncing on a regular basis, it began to seem like a technical issue, as opposed to a human one.  After the Whois service and domain management interface went offline all together, this new theory was all but confirmed.

The recent blackouts in Venezuela have been widely covered in the press and even have their own Wikipedia page.  However, we were slow to make the connection between this development and registry operations.  That changed when employees of the ccTLD manager CONATEL began to make reference to a “server change” as the eventual solution to the connectivity issues.

Initially, “server change” didn’t shed much light on the underlying issue.  Websites using a .ve domain have continued to work normally throughout the period where the registry has been offline, so at first we didn’t perceive any apparent issue with the parent servers.  However, that is eventually where we located the problem.

IANA lists five, in-country nameservers for .ve:

azmodan.ula.ve
ns1.nic.ve
ns2.nic.ve
ns3.nic.ve
ns4.nic.ve

…and two foreign nameservers:

ns-ext.nic.cl (Chile)
sns-pb.isc.org (United States)

Since we began reporting this story, only ns3.nic.ve of the in-country nameservers regularly responds when pinged.  Likewise, when checking an active .ve domain using a dig query, the foreign nameservers respond in the vast majority of cases.

The registry’s web-based tools run on the nic.ve domain, which in turn is delegated only to the compromised, in-country nameservers.  This explains why these tools are unavailable, while other websites using .ve domains continue to operate normally.

Can we state with 100% certainty that power scarcity has knocked the .ve registry offline?  The answer is no, but the circumstantial case is strong enough that we feel comfortable making this assertion.