Hacker News Reader

Comment by walrus01 | Hacker News Reader

this is some serious amateur-hour stuff on the part of the registrar. another example of why not to use random ccTLD top level domains. nobody remember when the .ly registry randomly canceled things they didn't like? when .cx canceled things they found objectionable?

https://news.ycombinator.com/item?id=12813065

https://www.theregister.co.uk/2017/07/10/io_hijacking_in_tra...

At least if you use .ca, .de, .us or .com/.net (or similar) you can have reasonable confidence that the root zone won't fail entirely.

If something goes catastrophically wrong and kills your business that is run by a .CA domain, CIRA knows that businesses in Canada have access to legal recourses... Do you have the same with a .ly domain?

View on HN

This case appears to be the registrar's fault, not the top level domain's fault. Unless 1and1 uses a "sub" registrar for .sm domains (which is actually quite likely) then I would say the moral of the story here is to not use shitty 1$ domain registrars who if I remember correctly have very bad support reviews.

In my opinion and based on past experience, all resellers of small-weird-country ccTLDs are equally shitty and have equally terrible customer service. Margins are very thin. At least if I buy a "new" TLD from a company that resells one of Donuts LLC's huge number of new generic TLDs, I can have some confidence that Donuts actually runs a 24 hour operation.

The ICANN vetting process and procedures to set up a new gTLD (let's use .network as an example) are much more thorough than the traditional two letter ccTLD. There are ccTLDs run by countries that edit the zonefiles by hand and don't even have a WHOIS server online.

for example using the current issue, nic.sm doesn't even run https on their webserver.

Or if I buy a .com from namecheap I can set up 2FA at my registrar, point it at my own authoritative nameservers, and trust that it won't fail.

Namecheap has and does fail, there was a time where I waited 2 weeks for them to fix a bug that got rid of my glue records and I was just getting "We're looking into it." Eventually I just transferred to Google Domains and have been flying happily since. At least in my case it was just a personal domain ...

If it was a bug in their software, why did only your personal domain get affected?

Suspending all of a registrar's domains when they're behind on fees is also super weird, though. A more typical approach would be to just stop letting them perform new billable actions.

Suspending all of a registrar's domains when they're behind on fees is exactly the sort of thing that I expect ignorant bureaucrats at a small country ccTLD registry to do. It's probably run by some person in San Marino who has never seen the CLI of a router in their life. A number of small ccTLD are run by their host country's "ministry of communications" or local equivalent.

I struggle to see why this is problematic, to be honest. They (the registrar, not puri.sm) didn't pay their bills, so they get turned off. The story doesn't relay to what extent the registrar received reasonable and timely warnings about this, although with a bit of guesswork, it doesn't feel absurd that perhaps they simply failed to act on such warnings, like, at all.

If a SaaS doesn't pay their AWS bills, they get turned off, it's not on AWS to keep the SaaS' customers running, and if AWS doesn't pay their electricity bill - - etc.

The registrar is merely the path to edit registry records; most of the ICANN agreements and registry-registrar agreements are structured to minimize exposure of registrants to bad/failed/incompetent/evil registrars.

There are some registries which don't have registrars, and in that case "suspend the registrant's domain name until paid" would be a reasonable expectation, but it's definitely the expectation of most registrants that their registrar isn't providing availability-critical service, merely facilitating updates. (Unless the registrar is also providing DNS hosting, which is generally a bad idea IMO.)

Part of the problem is that icann policies for legacy ccTLD network engineering and backend support systems are very lax compared to the operational and technical requirements for a new gTLD.

To be fair ... a smaller TLD probably doesn't have enough transactions with a smallish registrar for that to become an incentive.

1and1 != 101

Reply on news.ycombinator.com