Dealing with rebel baloney (1.Viewing)

  • Topic Starter rlm
  • Start date
  • Replies: Replies 13
  • Views: Views 1,808
Baloney at Rebel ?!?! (gasp) Not possible ;)

Maybe I can help. What can I do for you?
 
Hi Brett, thanks so much for following up, that is much appreciated!

I recommended Rebel to someone who was buying their first .ca domains. But we've run into a couple of issues that I didn't know would be a problem at Rebel, as its not an issue at other registrars. Chatting with the online support just provided us with incorrect information too.

Here is what happened:

1.My friend signed up at Rebel and registered a single .ca domain name. Later that day, they then bought a second .ca from a third party and transferred it to their Rebel account. First minor complaint, why would the transfer take a day to complete when nearly every other registrar transfers .CA domains instantly? It just added confusion because I told them .CA transfers are instantaneous. So there I am trying to figure out what went wrong over the phone with my friend and it turns out its just Rebel's way of doing things I guess... For the record - not a fan of that.

2. The domain eventually transferred into Rebel under the seller's Registrant info, but then Rebel gives no way to allow their own customer to update the registrant information. It just said the contact was locked. So I tell my friend, oh, they might just lock it by default on your behalf for security reasons, but that there is most certainly an unlock button/option somewhere! Nope. After searching high and low, no option to unlock was found. In fact it just said the Registrant specifically was locked, but didn't explain how long or why.

3. That led to contacting chat support and they said the Registrant is now locked for 60 days - preventing any changes to the Registrant. Wrong! Only TRANSFERS to another registrar are locked, not changes to Registrant details.

So, the domain in question has the following EPP status codes set for the newly transferred domain. They are:

clientTransferProhibited
clientUpdateProhibited
serverTransferProhibited

The serverTransferProhibited status is set by the registry after a domain transfer, preventing the domain from being transferred to a new registrar, NOT preventing anything else, such as updating the registrant.

All client*Prohibited epp status codes are set by the Registrar, i.e. Rebel. That also means you can unlock it.

The real problem here is that Rebel isn't allowing their own customer to update their own domain with their own registrant info. Seems messed up, no? Depending on the situation, you could be putting either the old owner, or the new owner at legal risk. This is why we were concerned about correcting this Registrant info asap. What if a CDRP is filed on this domain?? The domain gets locked with the wrong Registrant info! I can only imagine the mess this would cause. If this happened, it would be 100% Rebel's fault! Maybe you're thinking, what are the chances of that?? But I'm thinking, what are the consequences?

So now I just asked this person to log in again today and see if the "unlock" option has come up anywhere yet. Now it says the Registrant is locked until Nov 12, which is 7 days after the transfer. Obviously that is better than the 60 days. If the website had been clear about that from the beginning, that would have been nice and would have saved a lot of frustration. And clearly the support people don't know what they're talking about either - they insisted it was locked for 60 days, causing more concern.

But even the 7 days is kinda baloney, if you ask me. I'm guessing that Rebel has just made it their policy (that is not disclosed anywhere that I saw), to use the clientUpdateProhibited epp status code to make up their own rules for locking domains. While I could understand you might Lock domains by default on behalf of the client for security purposes, the client should absolutely be allowed to unlock it, any time.

Just so I could see what was going on, I tested out the transfer-in logic at Rebel, and there does appear to be an option to change the Contacts for the incoming domain transfer during the check-out process (at least for me) and it pre-populates the contact info for the incoming domain with our own contact information from a previous Contact in our account (not defaulted to the old owner's information). So if that is the case, how did my friend have their incoming transfer default to the old owner's contact info?? Had it defaulted to the contact already in their account (from the .ca registration made earlier in the day), this wouldn't have happened either. So I don't even understand how this happened to begin with. But regardless of how it happened, the client should always be allowed to update their registrant details (unless of course it is the Registry setting the lock, i.e., the server*Prohibited status codes, which is not the case here).

So anyways, I'm just wondering what your perspective is on this. I personally don't think its Rebel's right to refuse to unlock any client*Prohibited epp status codes, ever. It seems self-evident that those are intended to be set at the client's direction, not the Registrar's whim, nor for any registrar to be able to refuse to unlock. Is there some sort of 7-day loophole in the CIRA regulations that Rebel is using to justify this?

Thanks!
 
While we're on the subject...

Forcing automatic renewal payments 45 days prior to the expiry period, with no option to turn off auto-renew, is baloney too (imo). Especially when you have nearly 80 domains there.

I understand it can help some people save domains they don't want to let expire, but the post-expiry period with cira is already 75 days to begin with, which means there are 75 days to help registrants renew/recover their domain even after the domain expires.

At GoDaddy I can wait 75 after the expiry date before I need to decide wether to renew or not, and at no additional cost. In other words, and the way that I look at it, is that Rebel forces me to decide on renewals 120 days earlier than at GoDaddy (i.e. the 45 days prior to expiry + 75 days after expiry = 120 days).
 
And to add to the baloney list, Rebel doesn't allow me to delete the nameservers. I literally don't want any nameservers until I'm ready to use the domain. I thought maybe that's what the _forced_ option is for "park with rebel" - but no, you're hijacking and monetizing my traffic - redirecting it to simcast.com. WTF? The sketchiness of Rebel as a registrar is growing by the minute here.
 
Given that our members own tens of thousands of domains Rebel would be wise to take the member feedback into consideration. I traditionally renew over 1000 domains every January 1st and I know I seek out Registrars that are responsive to domainers needs.

It will be interesting to get [notify]brett[/notify] 's response to some of these issues so that we can recommend Rebel as a domainer friendly registrar.
 
  • Like
Reactions: rlm
Alright. These aren't too bad. Here goes:

1. Correct, its not immediate. We know its not a great experience. We have a few batches that run throughout the day that complete the process. You'd experience up to a 8hr delay. Our CS staff is enabled to push through a transfer immediately - but that requires a call. Its in our backlog to fix this process and make the transfer available immediately.

2 & 3. Its for security, its on purpose. Our CS agents are enabled to release these locks but this interaction gives us a chance to verify the customers identity. Its really a 5 min call including verification. In the case the domain owner loses control of the account, when transferring or moving, we want to put in some friction to make sure these transactions are legit. Its a feature - not a bug. Given this is complaint - we judge the impact and value of a complaint by how many times we received it - and this isn't a big complaint. Help me understand the value here - maybe a phone call?

4. The 45-day period on charging is something we know is a common complaint. On the other hand it gives us lots of time to work out billing issues in advance of renewal - and its all a strategy to make sure your domains get renewed. If its a really big deal, One thing that would help me to help you is if you send me a personal complaint on the matter to my email. Worse case scenario, we can get you a discount or credit for the inconvenience. We can also give you full control over when your domains get renewed and when you get charged - but, as we've seen in the past, statistically speaking, more people lose their domains this way.

5. Deleting names servers? That is a feature I can look into. At least something that forces an nxdomain response.

6. Re domainers and investors - We're investing in being more to being valuable to individuals and small and medium businesses. We're helping them to get their business online and successful - website, ecomm, email, seo, security and more. This audience has typically has less than 10 domains. For our larger clients, we have a major accounts team that helps out with our bigger domainer-type customers, and those customers like that type of white-glove service. If the great people of this community want to talk further about account management, happy to make some connections.
 
7. And the simcast garbage. Yes, this is supremely shitty. :) I can explain further why but that's probably not valuable. You can easily set the parked page to a nice Rebel parked page by selecting "Park with Rebel". There are some older accounts where this Simcast setting is a default. You can fix this by switching DNS to "Park with Rebel". CS agents can also help you fix this. For what its worth, we don't get a lot of complaints about this so thats why its priority hasn't really changed - but personally, Im really not proud of it. I'm going to put together some changes to this and we'll start to make this better.

I'd love some input from the community on this one. Anyone care to take me up on a phone call?
 
brett said:
Alright. These aren't too bad. Here goes:

1. Correct, its not immediate. We know its not a great experience. We have a few batches that run throughout the day that complete the process. You'd experience up to a 8hr delay. Our CS staff is enabled to push through a transfer immediately - but that requires a call. Its in our backlog to fix this process and make the transfer available immediately.

Great. There's no doubt we're spoiled with .ca, so much so we've come to expect that convenience and instant gratification.

brett said:
2 & 3. Its for security, its on purpose. Our CS agents are enabled to release these locks but this interaction gives us a chance to verify the customers identity. Its really a 5 min call including verification. In the case the domain owner loses control of the account, when transferring or moving, we want to put in some friction to make sure these transactions are legit. Its a feature - not a bug. Given this is complaint - we judge the impact and value of a complaint by how many times we received it - and this isn't a big complaint. Help me understand the value here - maybe a phone call?

Well - I think its needlessly redundant from a security perspective. That's the entire point of the transfer lock enabled at the registry level. CIRA, as conservative as they are, thought the transfer lock set at the registry level was sufficient. And we did contact support - and they didn't know what they were talking about, saying it was a 60-day lock on the registrant name.

And from the security perspective, this new client created an account, tried to purchase a hand-registered domain via CC, the name on the account, the registrant, and credit card all matched, in fact they were held up buying the initial domain while she went through additional verification of her credit card with Rebel. So she passes that, then she transfers in a domain and has a valid auth code, I'm not sure what more you could expect from them that an additional 7 days of lock is going to provide. Its not like they can transfer it out. And then if you're going to lock the incoming registrant, you need to be darn sure its clear to that user how to pre-specify the new registrant details BEFORE the transfer in, so that its not really an issue. its confusing to a new domain owner who just paid aftermarket prices for a new domain, transfers that domain in and then sees that they aren't even the registered owner and are told they can't fix it for 60 days. As you can imagine, that would be disconcerting to anyone not used to buying/selling domains.

Again, I don't think its really a security issue, and I wonder what CIRA would say about locking a customer out of updating their own domain. You can say now that its as easy as a phone call, but that is not explained anywhere, and our attempts to contact support were fruitless, as previously pointed out.

brett said:
4. The 45-day period on charging is something we know is a common complaint. On the other hand it gives us lots of time to work out billing issues in advance of renewal - and its all a strategy to make sure your domains get renewed. If its a really big deal, One thing that would help me to help you is if you send me a personal complaint on the matter to my email. Worse case scenario, we can get you a discount or credit for the inconvenience. We can also give you full control over when your domains get renewed and when you get charged - but, as we've seen in the past, statistically speaking, more people lose their domains this way.

I do understand your perspective on this, and its not a huge issue for me personally. However, put the power in your customer's hands. Maybe let them choose the auto-renewal period that works for them and explain why you recommend the 45 day time frame. That would be perfectly acceptable to everyone.

brett said:
5. Deleting names servers? That is a feature I can look into. At least something that forces an nxdomain response.

Great. Although its not used that often, it is certainly necessary to protect a domain when you're not ready to use it.

brett said:
6. Re domainers and investors - We're investing in being more to being valuable to individuals and small and medium businesses. We're helping them to get their business online and successful - website, ecomm, email, seo, security and more. This audience has typically has less than 10 domains. For our larger clients, we have a major accounts team that helps out with our bigger domainer-type customers, and those customers like that type of white-glove service. If the great people of this community want to talk further about account management, happy to make some connections.

I get that too. Domainers need rock bottom prices, so there's not always a ton of profit, but it is still essentially free money - provided you give them the tools to not need to tie up your customer support people.

Suggestion - maybe offer an "advanced user" option, something a user can toggle on/off in your account preferences that automatically unlock advanced features. This way it doesn't confuse novices, but if the user needs them, they can turn them on.

With as difficult as it is to talk to support, and with as many wrong answers as we get from support (and I'm talking generally, not Rebel in particular, but _every_ business), it makes more business sense to empower users, not frustrate them with arcane business strategies to control your customer's choices.

For example, I just wanted to upgrade my Rogers phone line to unlimited U.S. long distance instead of the cheaper "preferred rate option". Should be simple, right? Log into my Rogers account and upgrade it, right? Well no. To add the one service, I had to remove the old one, and _god_forbid_ we let a customer downgrade their account (even if they're really wanting to upgrade it) without running through the gauntlet first. I spent 90 effing minutes trying to get this accomplished due to a spectacular combination of shitty technology and inept employees. Its that kinda baloney I'm talking about, needless frustrations and forcing people to use support when support is probably already overworked, understaffed and under educated for the position. Its the reality of today's world, most people don't want to talk to anyone (because they know the baloney that will ensue), they just want to get to the point and fix it themselves, so please, when designing administrative interfaces, let the customer do what they want, make it intuitive on how to do it and then you can lay off 90% of the customer support team... Every business' goal should be to never have a customer need support, let alone force them to use it.

I'm sure you can take a poll here from all the domainers. They don't want a white-glove service. They want a proper admin area that allows them to do what they need to do, efficiently, and certainly without needing to talk to support. I'd bet money on that!

In any case, I certainly appreciate you taking the time to respond. Hopefully this is at least some decent feedback for you. I don't really need any further responses on it, I don't expect any quick fixes, but I've given my thoughts, hopefully you can make use of them.

Cheers.
 
Doh. Ok [notify]brett[/notify] maybe I'm not done just yet.

I just went to set up an A record to point to a placeholder page rather than your parked page, only to see that apparently rebel doesn't offer free dns with a domain purchase?? I don't even see that I can add it on as an extra service. I'm pretty sure every registrar I know of offers free dns with a domain registration. Am I just having trouble finding this on Rebel?

Thanks.
 
Ah, ok, I figured it out. I knew it must be there, but, yeah, the terminology is the issue.

After you save the "park with rebel" option, then magically the options to add dns records appear. Obviously knowing the term "park" and seeing that simcast page gave me an aversion to the idea of even considering the "park with rebel" option.

So that could probably be clearer, like, it could be two separate options, "park with rebel" if you want to get the simcast crap (as implied by the term "park"), and another option that says "Rebel's Advanced DNS". That would have been much clearer, at least from my perspective.

Thanks!
 

Sponsors who contribute to keep dn.ca free for everyone.

Sponsors who contribute to keep dn.ca free.

Members who recently read this topic: 1

Back
Top Bottom