LittleBizzy

Dominate local SEO with a regional SlickStack cloud server for just $39/month!  Order Now

Why You Should Never Use Domain Registrar “Resellers”

One common issue we see amongst our managed hosting clients is the instability of their DNS resolution. Even when requiring clients to point their NS (nameservers) at our agency CloudFlare account, which is still the fastest resolving DNS provider in the world, we still sometimes see a client whose domain is receiving “down” notices among our monitoring partners like Uptime Robot, Pingdom, etc.

The down time notices are usually timeout errors (code 522) meaning that while the server may be completely fine, the domain is not resolving around the world in a stable way during some of the uptime tests (pings).

Usually, web browsers and other applications will point the finger at the origin server — in our case, that means LittleBizzy’s network. This is because the 522 error was originally used to report that a remote server was taking too long to reply back to packet requests.

However the truth is that the 522 error can have many different causes.

The vast majority of the time when we notice 522 errors cropping up for a LittleBizzy client, we check their domain’s WHOIS, and nearly every time we see they’ve registered their domain via a registrar “reseller” such as BlueHost, HostMonster, and so forth. This means that rather than purchasing their domain directly from a “top-level” ICANN accredited domain registrar, they are (usually unbeknownst to them) paying a reseller to manage their domain indirectly.

Even some of the most popular registrars on the web are in fact RESELLERS and not top-level, such as NameCheap, which was still a reseller of eNom up until 2013 (I’m not sure if 100% of their domains are now sold directly or some still managed via eNom?).

You see, the issue with “resellers” is they must connect to whatever top-level registrar they partnered with via an API, which is often not designed very well, so this extra hop(s) combine with coding errors and network/database issues to commonly cause a delay in DNS updates, not to mention a complete failure of DNS resolution in many cases.

Example: rather than “the internet” asking eNom directly for DNS information on your website, it must ask Bluehost, who then must ask eNom, who replies to Bluehost, who then replies to “the internet”… does that sound efficient?

So where should you buy your domains? ALWAYS check to confirm your registrar is top-level accredited by ICANN. Usually this means they will have the ICANN logo at the bottom of their website footer, but in case they are “faking” it, it’s better to check the ICANN website directory instead.

For the past few years our favorite registrar has been NameSilo, based in Arizona, USA. They not only have cool features like 100% WHOIS privacy, but their prices are among the lowest too. Not only that, but their company is focused ONLY on domain management, and nothing else, and they’ve pledged to keep this vision in the future. Just like you typically find the best Chinese food at a restaurant that only focuses on Chinese cuisine, it’s my belief that compartmentalizing your “stack” into partnerships with companies that maintain a narrow focus tends to provide the best performance, not to mention customer service.

So if you are reading this, stop what you are doing and transfer your domains to a top-level registrar focused ONLY on domains. There aren’t that many such companies out there, so if in doubt I highly recommend checking out NameSilo if they support your domain extension.

For legal reasons, a US-based registrar can offer you the best protection too, because of the US court system’s reputation for fairness, not to mention that the US now has courts focused entirely on internet technology as well.

If you need a non-US alternative that is simple and reliable, I’ve also used InternetBS in the past, based in the Bahamas (now UK parent company).

About the Author

Jesse

4 thoughts on "Why You Should Never Use Domain Registrar “Resellers”"

  1. Tamhas says:

    Thanks very much for this Jesse. I have indeed noticed when checking domain propagation with WhatsMyDNS.net that i get a lot of red crosses, that are still there long after any DNS updates. Appreciate the pointer and will check your guys out. Always look forward to your well-researched and hard-learned blog articles. Thanks again!

    1. Jesse says:

      My pleasure Tamhas. Cheers!

  2. snake says:

    This is not strictly true and is rather misleading.

    Using enom as an example. If you register directly with enom for example, you use enom’s dns, if you go through most resellers, you still use enom’s dns by default. Same applies to GoDaddy and the rest. So it is going to make no difference whatsoever.
    I have been an enom reseller for 16 odd years, and use WHMCS to integrate with them. In all those years and thousands of domains, I do not recall any problems with the API like you describe. The updates have always occured just as fast as if I logged into the enom control panel and did it from there. In fact I can recall more problems with enom’s own control panel breaking.

    The exception is if the reseller runs their own DNS servers, such as if they are also a hosting provider. But in this case, even if you have registered your domain name directly with the domain registrar, most customers will have set it to use their hosts DNS anyway, so it is still a moot point as the registrar is irrelivant in this case.

    These days I mostly use cloudflare for DNS.

    1. Jesse says:

      It’s totally true and not at all misleading.

      Just because you’ve noticed your reseller API loading pretty fast doesn’t mean that it’s not yet another potential point of failure, errors, and poor performance (let alone guaranteed latency).

      On top of that, you have yet another layer (cPanel/WHMCS), for even more bloat.

      Just because you are making money from reselling, and apparently cannot even provide your real name or business, doesn’t negate any of these points.

Leave a Reply

Your email address will not be published. Required fields are marked *