By accepting you will be accessing a service provided by a third-party external to https://whizzbangsblog.com/

6 minutes reading time (1171 words)

My Registrar/Registry Nightmare

20190828_security DNSSEC nightmare

During this past week I’ve had an experience with a domain name that can only be described as a nightmare. I found myself with a domain stuck in a “no mans land” between two registrars, the registry and a bunch of crazy policies. So what happened?

Escrow.com

The domain name in question was simcast.com and one that I have personally owned for nearly two decades. We’ve been building some really awesome tech at ParkLogic and decided to use this domain as the flagship lander for a lot of traffic. Since it was in my personal name, I decided to transfer it from my personal registrar account at Epik to the ParkLogic Enom account.

I should say that the ParkLogic Enom account only existed due to legacy reasons and I was just trying to tidy things up. During the testing process we discovered that the domain was no longer resolving for a growing number of nameservers…..one of which was Google’s public DNS. This wasn't a really good situation because if the domain went live we could be losing a lot of a traffic....plus one for testing!

I must admit that I’d never seen behaviour like what we were seeing before and assumed initially that it was due to some weird DNS propagation delays. I waited 24 hours and assumed the Internet would sort itself out. Things didn’t improve, in fact, they only got worse.

I contacted the Enom support desk and listened to really bad 80’s music for about 30 minutes while on hold. Seriously Enom, you really need to get some better music! The support person told me that despite what I could prove that everything was fine…..essentially they were clueless.

After doing a LOT of reading I put it down to a problem with DNSSEC. You may be wondering, what the heck is DNSSEC? In a nutshell it’s a relatively new security protocol designed to help ensure domains are not hijacked, DNS poisoned etc. It's one of those innovations that come out of ICANN type meetings....oh dear!

What had occurred is that Epik (being a very progressive registrar) had enabled DNSSEC on the domain (which they should) but Enom doesn’t support DNSSEC other than through a manual process. This process starts with the help desk person asking me to provide them with my existing DNSSEC string for them to load into their backend system.

Just think about this for a minute. Let’s imagine I’m a plumber that has a website and I’ve just managed to transfer the domain to Enom, they are now asking me to provide them with what?????

Being relatively technically literate (I know nothing about plumbing btw) I then went back to Epik and asked if they could provide me with this magic string. At which point I need to digress and say a few things about Rob Monster, the CEO of Epik.

He has bent over backwards to help in this situation and has been constantly communicating with me via skype. He’s even engaged his team to help sort out the problem, even though it wasn’t actually his problem to begin with! This is what I call a class act.

The magic string isn’t as simple as you would first think as it's a combination of a number of discrete factors all smashed together and by rights, it shouldn’t be easily accessible (ie. not Epiks fault). Rob suggested transferring the domain back to Epik and I immediately did so…..only to find that it was blocked by Enom.

This is the point at which I began to tear my hair out in frustration. After listening to some more 80s music I spoke with yet another Enom help desk person and they indicated they couldn’t approve the transfer because it was within 60 days of being transferred.

A few things on this. The transfer was approved by Versign but knocked back by Enom due to their own policies. It was at this point in time, the help desk person (nothing against them BTW) said that I’d agreed to their terms of service and therefore they could not transfer the domain back to Epik.

I responded by saying that since Enom was not able to support DNSSEC for this domain then could they please approve the transfer. The answer to date is, “no”. Seriously???? Why argue about terms when the client is clearly very aggravated because their domain is effectively dead in the water?

During this whole process, I did manage to get the Enom help desk person to delete the DNSSEC entry (they didn’t know this was possible btw). Rob, also deleted the entry at his end, contacted Verisign and followed up with everything he was doing. You go Rob!

I then asked for an Enom supervisor to call me back…..which they did. They indicated there wasn’t a process to override the approval of a domain transfer less than 60 days and they would have to speak to the tech team about it. I think at this point in time I was looking for a way to end my misery but instead I persevered.

I responded by saying that Enom should not accept inbound transfers for domains with DNSSEC enabled as it is something they are yet to fully support. I wouldn’t be surprised if there are literally thousands of domains that are caught in my situation at Enom and are not properly resolving around the world. It would only take a few hours to scan the entire Enom domain list to work out which ones are failing.

I would have thought that this is a HUGE class action exposure for Tucows (Enom’s owner) as businesses must be losing a lot of money due to this problem…..but I’ll leave this to an enterprising lawyer to work out.

I should also state here that all of the Enom help desk people have been pleasant to talk with but it’s clear they have their hands tied. BTW, the help desk system is terrible....just try and find the logout button (maybe I was blind with rage?). I’ve had an account with Enom for well over 15 years and I’m wondering why I’m keeping it there.

At long last I've had some good news. The DNSSEC records have finally been deleted, propagated and it looks like simcast.com is now correctly resolving…..fingers crossed! I can only hope that I can transfer the domain out of Enom…plus all the other domains I manage.

Is this really Enom's fault? Well yes and a little bit of no. In my opinion, this issue is firmly in ICANNs court where it's clear they never invisaged that a domain could be caught in this manner. It also brings up an important issue, if you are selling a domain make sure the DNSSEC is TURNED OFF prior to transferring the domain. If you don't do this you may end up listening to a LOT of really bad 80s music.

The Health Gamble
Saturday Musings - My Fretty Friend

Related Posts

 

Comments

Epik on 28 August 2019

Thanks Mike.

This is an important issue -- DNSSEC is broadly recognized as a best practice. Some legacy registrars might lack the engineering capacity to adapt their legacy software to new requirements, e.g. new gTLDS some years ago and now DNSSEC, and soon RDAP. This presents challenges when new practices show up.

Over the years, Epik has had a fairly constant heavy investment in product development with high personnel continuity. When a new feature is needed, it can often be deployed in a matter of days, and even hours, depending on the new requirement. We keep the engineers interested by also staffing new projects so that nobody gets bored or stale with their skills.

In this case, the domain was moved off of Epik and then switched to non-Epik DNS with DNSSEC still active. When DNS was switched back to Epik, the domain began resolving again. Our TTL is a very tight 300 seconds, but most other DNS providers

We are evaluating whether to disable DNSSEC for outgoing transfers by default to prevent situations like this one. Our DNS actually keeps working even for outgoing transfers. We
do allow non-Epik domains to use our DNS and forwarding services for free.

Anyway, good topic.

Thanks Mike. This is an important issue -- DNSSEC is broadly recognized as a best practice. Some legacy registrars might lack the engineering capacity to adapt their legacy software to new requirements, e.g. new gTLDS some years ago and now DNSSEC, and soon RDAP. This presents challenges when new practices show up. Over the years, Epik has had a fairly constant heavy investment in product development with high personnel continuity. When a new feature is needed, it can often be deployed in a matter of days, and even hours, depending on the new requirement. We keep the engineers interested by also staffing new projects so that nobody gets bored or stale with their skills. In this case, the domain was moved off of Epik and then switched to non-Epik DNS with DNSSEC still active. When DNS was switched back to Epik, the domain began resolving again. Our TTL is a very tight 300 seconds, but most other DNS providers We are evaluating whether to disable DNSSEC for outgoing transfers by default to prevent situations like this one. Our DNS actually keeps working even for outgoing transfers. We do allow non-Epik domains to use our DNS and forwarding services for free. Anyway, good topic.
mgilmour on 28 August 2019

Many thanks for your assistance with this matter. I do not like speaking negative of any company in a blog post but once again, Enom has dropped the ball. Likewise, I'm very happy to speak positively of a company that goes above and beyond and Epik did this. Well done and keep up the great innovative work.

Many thanks for your assistance with this matter. I do not like speaking negative of any company in a blog post but once again, Enom has dropped the ball. Likewise, I'm very happy to speak positively of a company that goes above and beyond and Epik did this. Well done and keep up the great innovative work.
Wolftalker on 28 August 2019
Important to know

Thanks for this information - good to know.
Sorry you had to learn it the hard way

Thanks for this information - good to know. Sorry you had to learn it the hard way :)
mgilmour on 29 August 2019

It was a tough lesson and one that I thought others should be aware.

It was a tough lesson and one that I thought others should be aware.
Already Registered? Login Here
Guest
Friday, 29 March 2024
If you'd like to register, please fill in the username, password and name fields.

Captcha Image