The death of a TLD | Hacker News Reader

The death of a TLD

blog.benjojo.co.uk

267 pointsjanvdberg165 comments

This isn't what makes investing in other gTLDs a danger. It's that some are offering registration for pennies, causing them to be almost entirely populated by "bad" domains. For example, .fun is 80% spammy domains, creating a strong incentive for all manner of services to blacklist the entire TLD.

https://www.spamhaus.org/statistics/tlds/

Can a TLD have ToS to revoke a domain being used for spam?

Otherwise, after sufficiently ruining .fun, I'm sure the spam crowd will just move on to the next cheap TLD until that one gets saturated and so on.

It can, but I mean really blocking spam at the TLD level is not the most effective way to do it.

If I control the rDNS for a public IP I can set it to anything I want. Of course if I want any chance at all for mail delivery the rDNS for the smtpd needs to be the same as its 'forward' DNS name and name in the MX records.

But you're much better blocking by IP RBL (ex: many /16 to /18 sized blocks of taiwanese DSL ISPs are blocked in all the major RBLs), using tools like spamassassin on your incoming smtpd, opendkim integrated with your smtpd for incoming DKIM verification, and generally filtering by content.

It's not all .fun and games

.games

Same thing happened with .info domains. I used to trade domain names when I was in college. Initially, .info used to be decently well-used and respected.

Then the registrars started offering 1st year registration at $0.99/year and all the spammers jumped aboard.

Came to a point where .info was the equivalent of .spam

The other issue is with dark UI patterns in third party resellers, sure you can get some weird gTLD for $1 for the first year. But then if you actually build something that uses it, maybe the next year and the third year you find that the price is now $89/year. Totally undisclosed before you buy it.

At least if you buy a traditional ccTLD like .ca , or a regular TLD in .com , .net , whatever, you can expect pricing to remain consistent.

I really hate this. It's super scammy. Although namecheap does show a little message letting you know it costs more to renew.

But then it sounds like the $89 is not the general price of the TLD but rather your site as determined by the rate on how the registrar's been receiving queries for your domain on their DNS servers. Can't you "reset" the price by transferring to another registrar?

No, because it's not actually the resellers doing this. It's the people who own the tld doing the scammy pricing.

You mean the registry has the registrars do that? Do registries even have view on the popularity of different domains below their TLD? I didn't realize that they received requests from resolvers that included second-level domains. I thought it was only the registrars that received that, not the registries, but I guess misunderstood DNS if so, because it makes sense.

It's not popularity based. Everyone pays more to renew and it's a lot more than the initial price.

In the last year, I got hundreds of spam emails, each with a valid DKIM signature for a unique .bid domain registered at NameCheap. It costs less than 1$/year/domain.

I mailed NameCheap multiple times about this, they keep telling me they cannot do anything about it.

Did you try the TLD's administrative contact and did you make sure you are using tools that report to Spamhaus or other blackholes?

.bid seems to be 35% bad which is not all that bad if they have been offering $1 domains for long. So maybe they take some actions through the registrars to stay bellow being presumed spam by default or maybe not enough of these unique domains are getting reported..

You think the email space isn't an almost monopoly that actively makes it hard for others to get in?

Why do you think it's a monopoly? I think SMTP is more often on premises at organizations than web services for example.

The hoops to send have existed for a long time and simply evolve. A push protocol without trust is a pretty bad idea after all.. So bad the fax machine needed the legal system to inflict severe punishments for the physical resources consumed by unwanted push (in theory if not practice.)

> With that, comes the question. Was anything lost?

Well, the real question is, is there some regulation from ICANN in regards of terminating a gTLD who is not for private use? I can understand that if I want to waste 185k into my very own gTLD then I can terminate it whenever I want, but what happens when I commercialize it?

That's a great question. There's never really been any likelihood of the operators of .com, .net, etc. going out of business, but a lot of these new TLDs very well could, and many were bought by smaller parties that aren't your Amazons or Googles.

Does ICANN have a plan for transition for failed TLDs? It's not unrealistic to suggest the owners of .space or something could just go belly up.

> There's never really been any likelihood of the operators of .com, .net, etc. going out of business

ORLY? Where were you in the summer of '87?

Gestating, personally.

But I think it was pretty obvious that the poster you're replying to was referring to the commercialized era of the internet.

Thanks, Joke Explainer. I would have never got that.

(Although the other theory is that the poster was born after 1994 (not long odds on that one, given the local demographics), and doesn't know much about the Internet's history prior to Eternal September.)

EDIT: The Gestating thing was clever. Thank you.

Used to work in the space. The long answer is complicated, and to be truthful I don't remember half of it, but the short answer is... EBERO. Essentially, someone else will take the TLD from you. What happens long term if the new operator doesn't want it, I don't quite know.

There's a provision for this. TLD operators have to upload all registry data to an escrow service. If the TLD operator goes out of business or turns out to be technically incapable of running the registry, ICANN can access this data and transfer the domain to another registry. ICANN has contracts with several registry operators to take over in case of an emergency like this.

https://icannwiki.org/Data_Escrow

https://icannwiki.org/Emergency_Back-End_Registry_Operator

Interestingly, two of the dead TLDs (.sapo, .meo) were owned by the same Portuguese ISP/media company — both tied to specific brands, neither of which really justified a TLD

Question: would it be correct to have an email of the type name@TLD? Example:

John@com

Is this kind of name spec-compliant?

Yes it would! We used to have a fake TLD for our internal Network. It just works.

Yes, it is. But as with many things on the internet, it might be spec compliant but nobody can use it because most programmers didn't actually read the spec and thus implemented what they think is the spec.

Most websites will probably validate email addresses with regexes that expect a dot in the host part.

I still have trouble using .co instead of .com even. No dot would definitely throw a bunch of sites off.

The situation is even worse with more obscure TLDs like .FYI.

I honestly cannot register to a good 80% of the sites I want to.

I have a .red domain and haven't hit any issues so far.

There is also a human problem to consider, my spouse owns surname.com (their address is firstname@lastname.com , we run our own authoritative DNS and manage the MX records for lastname.com) , a bunch of people out there assume that they are such a foolish, technically ignorant person that they don't know how to properly format an email address. To the extent that signing up for some things in person just results in time-wasting questions and "what, really", so they just give a gmail address to some people.

I remember receiving a phone-call from a tiny online shop - they seemed to think I'd mistyped my email address, because it was "their-company@example.com".

They found it unbelievable that my email address could match their domain, and assumed I'd made a mistake.

I do this too and it's most fun when giving my email address to physical stores. One time I was in a random optician's shop and had to ask what the store was called, "Such and such" - "alright then, that would be such and such at example.com".

I use a catchall as well, but if I think my email address is going to be read by humans somewhere, I try not to throw people off by using something like firstname.companyabbreviation@example.com.

Absolutely. I am always worried someone will think .co was me being silly and replace it with .com when giving it to people in person. I normally add "no M" to make sure they realise it's intentional.

Because of this problem I'd be really hesitant to use .co for anything I care about unless I was Colombian or doing business primarily in Colombia.

Unrelated to TLDs but on the subject of email validation: I like to put a +<some sort of tag> after the name on my Gmail address. This is a perfectly legitimate thing to do to tag your emails. Most websites I've come across don't accept such an email address.

I've also yet to find a website that isn't fooled by gmail's dot trick. They all thing myname@gmail.com is a different address to my.name@gmail.com. In fairness this is not an email standard, but you'd think devs would have copped this by now and started to recognise multiple signups from the same user

Validator[0] node package seems to have a "normalizeEmail" function, site operators just need to start using it.

0: https://www.npmjs.com/package/validator

Or maybe they should send email to the address their users give them?

A human creating many alt accounts may not be desirable by a website owner, so requiring multiple real email inboxes or running a mail server adds another barrier to prevent spam.

Not really. I understand why website owners would like that, but it's simply not possible. In the worst case user will use mailcatch.com, aliases or one-time email accounts. No way you can check if the e-mail address is a "real" one. Fortunatelly.

You can’t entirely prevent it but you can certainly raise the bar enough to deter a substantial fraction of those signing up multiple times. Whether that’s worth the effort or not it a business decision.

Well now I’m really happy that some library doesn’t know how to remove the sub-addresses on my custom e-mail setup :-)

Other email services might not ignore periods, and might really have separate myname@example.com and my.name@example.com users. If someone is going to make a site that tries to ignore periods for equality, then they should hardcode it to email domains that they know do that.

Yes, that's what I meant by it not being a standard. They should be making a special rule for gmail

Honestly though: why bother? If you're really set on opening a second account, email validations won't stop you. If I as a service provider want to stop you, I'd check your address, credit card number, vat Id, etc.

If you're unsure whether you've already registered an account, I could understand the frustration of finding your "proper" dot configuration, but as a developer I'd figure that to be your problem.

Still works on Twitter an other top 100 sites, but many examples of regex matching skip this valid and useful case.

With Gmail you can move the dot around, it's effectively stripped, to make sorta unique ones. But everyone serious about validating against Gmail knows to strip it out.

I'm in a habit of putting it in and it seems to be about 50/50 as to whether or not any given site will accept it. Surprisingly, I've run into at least one YC company which doesn't like it.

It's rarer now than in the past, but I too still encounter sites occasionally that won't let me use the +label form.

I'm in progress to migrating to an e-mail in my own domain, and I'm enjoying the extra control it gives me. I now use e-mails in the form of label@username.mydomain, which get internally translated to username+label@mydomain. Beyond solving problems with broken registration forms, it also makes it more difficult for spammers/data brokers to normalize the address - I assume most won't bother.

I wish people would stop using regex to validate email. Literally the only way you can check if an email address is a valid one is to send that address a validation email ("Click this link to confirm this is your email address" type thing).

Validation emails also come with the added benefit of ensuring people enter their correct address (is not just randomly mashing the keyboard). Of course that doesn't stop them from using multiple addresses nor those burner address services, but neither would regex.

The problem is validation emails take more dev time to build so some people get lazy and use form validation such as regex instead.

Yes. About the only thing you can count on is `.+@.+`

A little more elaborate would be [^@]+@[^@]+. It might still be possible to construct an email address that is valid and does not pass via comments in the address, but chances that this happens are low.

That's a little more elaborate but, as you note, wrong. Just send email to the address.

This does not match my favorite mail address, "@"@example.org

Validating email addresses with regular expressions can make sense from a UX perspective alongside sending a validation email after the address has been validated as "likely a valid email address".

If for example during a typical registration process the software merely sends an email instead of also trying to validate the address first the user either has to wait until the email has arrived before entering the remaining data or otherwise might end up with invalid registration data that cannot be retrieved anymore. In this case, the user would have to start over again.

This problem could be alleviated by having a two-step process, during which the software merely asks for the email address in the first step and the remaining data can only be filled in after the email address has been verified. However, depending on the requirements of the software it might make sense to not just ask for the email address but additional required information during the first step as well, in which case validating with regular expressions provides a better user experience through feedback.

> Validating email addresses with regular expressions can make sense from a UX perspective

... only to people who are not listening to the complaints from users whose perfectly valid mailboxes are rejected by such systems. It seems somewhat hypocritical for designers to go on about "good user experience" when the user experience in practice turns out to be that it is impossible to give the system their actual electronic mail addresses at all.

* https://github.com/kdeldycke/awesome-falsehood#emails

It'd be interesting to investigate if there's useful common error patterns that can be detected and then prompt the user to check. E.g. "you entered an e-mail address @gmmail.com. Did you mean @gmail.com?"

Then you could do the hard-fail checks very conservatively and still catch some mistakes early.

One solution would be to be lenient as to what address patterns to accept, e.g. using a regular expression such as /\S+@\S+/ that catches common entry errors but doesn't keep the user from entering uncommon but valid patterns.

The idea here is to help the user avoid mistakes not to actually verify the email address. That's happening at a later stage, i.e. when the user clicks on a confirmation link.

>using a regular expression such as /\S+@\S+/ that catches common entry errors but doesn't keep the user from entering uncommon but valid patterns.

your regex is too strict and doesn't accept all valid email addresses. my."really uncommon".email@is.valid is a valid email address that you would be rejecting.

the sane regex is /.+@.+/. Anything beyond checking for an @ is getting into very complicated territory (even the domain part allows stuff like round and square brackets)

I concede your point. I haven’t come across that particular pattern yet but it’s certainly valid.

All you're checking is if the user has entered an at symbol. If your regex pattern is going to be that loose then what's the bloody point in even having one? I mean you're ultimately just going to rely on authentication emails anyway.

This expression not only checks for the @ symbol but also makes sure there are no white space symbols (which is a wrong assumption as user wongarsu has pointed out).

Anyway, the point is to assist the user, not to verify the email address actually is valid.

But if you're rejecting valid addresses then you're not assisting the user.

I don't care how they do it, so long as the service refuses to send any emails other than a confirmation email, until confirmed.

My simple gmail address gets added to some new service by someone with a similar name at least once a week. And those services may or may not ask for confirmation, but then proceed to not care either way. It's super annoying. I get that people sometimes can't be bothered to confirm an account, but it still feels somehow very wrong.

The operators of the .ai TLD for Anguilla have done this for a while and hit interesting bugs in mail clients.

(Also notable, they have an A record on the hostname "ai." - you can see their website at http://ai./)

the dot at the end is an ambiguity in a few specs. if I recall correctly, dns requires to end in a dot as it signals the root servers or something, but obviously can be left empty.

then browsers started to support it, but over time bugs pilled up and now it is treated as a different hostname (e.g. "www.example.org" is completely different to your browser than "www.example.org." even though they are the same to the dns spec)

then tls specs considers the dot in an earlier version, and they should be the same but because of the browser bugs it is all too much fun. my bank actually has a server that replies the same for domains with or without the root dot. but they only signed their certs for the no dot name, which again, is the same, but for browsers is kinda of not.

ah! living Standards.

The dot at the end has a technical meaning in two different contexts. The first is to disable search lists in the DNS stub resolver. If you try to look up, say 'ai', then the sub resolver is likely to append your current domain name during the lookup. Looking up 'ai.' disables that.

The other use is in DNS zone files where everything that does not end in a '.' get the name of the zone appended.

The for mail (SMTP) the dot at the end is implicitly present, and adding one is not allowed.

HTML/HTTP basically doesn't define semantics with respect to the dot at the end. That's why "www.example.org" and "www.example.org." are different. They are different strings, and nobody defined them to be equivalent. At the same time, the name is just passed to the stub resolver in many cases. So search lists may be applied under the hood.

Untrue. RFC 1738 was in fact quite explicit on this subject. It was almost universally disregarded.

* http://jdebp.info./FGA/web-fully-qualified-domain-name.html

ICAAN seemed to have prohibited this in 2013 [0], but "ai" still seems to be up so..

0: https://www.icann.org/news/announcement-2013-08-30-en

That's one of many ICANN rules which don't apply to country-code TLD operators.

Another example of a rule that's optional for them is ICANN's Uniform Dispute Resolution Policy. Indeed, only some of them have adopted it, with others using a variation and still others not basing any of their dispute mechanisms on the UDRP.

Pretty sad that this was prohibited for gTLD.

My (sister) company has the .schwarz tld, and they use blabla@mail.schwarz. Such a waste, really.

Your link will not work for all Systemd users, might want to mention that.

https://github.com/systemd/systemd/issues/6224#issuecomment-...

I get a "name not resolved" when trying to navigate to your link

are you using systemd?

Chrome on Windows

I am not aware of any specifications which would prevent using mail hosts on toplevel domains. However, dotless domain names are currently prohibited by the ICANN Board New gTLD Program Committee,[1] so actually creating one may be a challenge.

1. https://www.icann.org/news/announcement-2013-08-30-en

2. https://serverfault.com/a/721929/61174

Forget SMTP, you’d have more problems with bad email regexes on sign up forms that assume anything more than an @.

This is why people should write proper code to parse and validate email addresses and not use regex

regex are proper code when written competently

Assuming "competently" means "not using them when the grammar is not regular".

I don’t even try. I put my hands up and accept [anything] @ [anything]

Well, you can still check MX record for the second "anything", that should be pretty safe, right?

I don't think that's sufficient on its own. If there's a CNAME on the domain, you'd have to follow the chain of CNAMEs to find an MX record (granted, that's not very common, but I think it's valid usage)

Resolving proxy DNS servers do that for you. A successful transaction against a resolving proxy DNS server yields a complete answer with all of the alias chain and the final resource record set (or "no such name" indicator).

* http://jdebp.info./FGA/dns-query-resolution.html

After you removed the comments from the second anything, and checked that it isn't a raw IPv4 or IPv6 address. jsmith@[IPv6:2001:db8::1] is a valid email address, as is jsmith@(comment)example.com.

Though you could argue that there are good reasons to disallow ip-based email addresses.

Thanks, didn't know that! E-mail is really full of surprises. :)

Relevant informational RFC:

https://tools.ietf.org/html/rfc7085 (Top-Level Domains That Are Already Dotless)

Yes, and there are some traditional domains too with A records, at least this one:

  > host -t aaaa dk.
  dk has IPv6 address 2a01:630:0:40::58

I don't know if they run SMTP (my ISP blocks it) but at least it answers http://dk/ :)

Interesting but I suspect that whilst possible they would be reserved for the registry.

A bit like in x.400 you could have a mail address of say C=UK CN=brian" but only if you where the ADMD operator - btw my boss did have that email address when I worked on x.400

I'm probably alone in this... but I would like to see the registration of a new TLD that has restrictions on it where you cannot run ads on sites that use that TLD, or domain park, or re-sell at profit. It could become a nice little corner of the internet where people like us can run stuff for each other, and the unwashed masses never visit.

Our own little club under one TLD as it were...

> or re-sell at profit

That's not really enforceable, is it?

> It could become a nice little corner of the internet where people like us can run stuff for each other, and the unwashed masses never visit.

Why not register a domain and offer subdomains for sale?

tbh, I was actually thinking of this. However, a full TLD would be so much nicer.

Each person could have their own 'city' and being geographically-based, you could call it something like geocities. Or, if everyone has their own 'space' that they think of as 'my'...

Great Idea. Do you think the users would like animated gifs and sparkly background images?

That's the best part! We let them style their own website, so they can show off their own aesthetic!

> That's not really enforceable, is it?

I think so. It's just a matter of the registrar removing the feature that allows transfers of domains between accounts. I guess you can still try "selling" a domain by actually putting a price on forfeiting a domain back to the registrar and giving a chance to the "buyer" to buy it from the registrar at its price. This, however, puts the buyer at risk that the registrar might put an elevated price on the domain and also that someone else that was watching for a domain to be let go might buy it first.

In order to ensure that all registrars do remove the feature for this domain, the registry for that domain would have to include such a clause in the contract it would have with these registrars.

What if someone runs ads... on a gopher server? :)

Then they should be applauded for ingenuity and sheer nerve. And then executed.

> It could become a nice little corner of the internet where ...

dot-Jaruzel? You could make a religion out of that.

I think my ego is big enough already :D

Hey - it worked for L-Ron. Probably about as easy as monetizing a B2C SaaS play.

I don't understand this. Eg in the Sony case, why wouldn't they just hold on to it? They did the hard work, they paid up, keeping it on is not a bigger burden than keeping a registered trademark globally, I'd assume? Does anybody understand?

Saving money maybe? I believe it is 185.000 per year.

google search, since it was integrated to the address bar its super easy to find the right site and you longer have to remember or guess the address , hence the name has become pointless.

If I'm reading this [1] right, some TLDs can be renewed by a different party. In that case, "link rot" might become wholesale link poisoning.

[1] https://www.icann.org/resources/pages/gtld-registry-agreemen... "...ICANN's Preliminary Determination shall not prohibit ICANN from delegating the gTLD pursuant to a future application process for the delegation of top-level-domains, subject to any processes ... intended to protect the rights of third parties."

Overall the gTLDs are a good thing because some of them will become legitimized alternatives to .com for consumers, and thus weaken the power of domain squatters.

> [...] some of them will become legitimized alternatives to .com for consumers [...]

Like what?

New gTLDs have been around since 2013 -- five years. I can't think of a single one that I'd consider as legitimate as .com. I can, however, think of a bunch that are frequently used for spam and other abuse...

Have faith!

The Year of the Alternative gTLD is coming!

Any day now...

I think .app could have a bright future in the age of web apps. It has only just recently been opened up by Google for public registration[0].

0: https://get.app/

Why do you need a walled garden around your DNS? I'm not sure that involving Google in everything we do is a good idea.

I wonder how many websites are served entirely through Google. Browsing with Chrome or Chromium, custom DNS set to 8.8.8.8, domain name from .app, "cached" by AMP, serving an Angular app with Material UI, originally hosted on Google Cloud.

... showing Google Maps, using Google Analytics, Google webmaster tools, custom Google search, offering Google payments and some Google docs forms.

Google wouldn't even have to index it.. they know everything about it already.

Google has shown they can handle DNS with 8.8.8.8

I trust Google to have the internet's best interests at heart way more than I trust GoDaddy and their ilk.

.google? Obviously not generally use, but used quite a bit by Google and entirely trusted for that use.

On the contrary, these gTLDs have only increased the value of .coms.

... and why is that?

A glut of goods perceived to be lower quality in the market will increase the desirability of the more "exclusive" higher-quality options (in this case, the .coms).

Like where I'm in India, Nike is substantially more expensive precisely because there are too many crappy shoes in the market. Nike is more "exclusive" and thus, pricier (and vice versa).

Another reason is the low education among ordinary users about the new TLDs. Everyone automatically defaults to assuming that your site is on .com

Companies stand to lose a lot of type-in traffic because of this. Which is why as soon as a business becomes large enough, it tries to go for its .com version. But since the .com version is already taken, and the owner knows the growing company wants it, he can dictate a higher price

> Nike is substantially more expensive precisely because there are too many crappy shoes in the market. Nike is more "exclusive" and thus, pricier

But is Nike expensive because they want to be exclusive, or because there exist other players in the shoe market? For example, I could invent a flying car and sell it at high prices, so it's both a flying car and a status symbol. Then in 20 years, my patent expires and others can make cheaper models, but if I don't change my price, my brand brand will maintain its status symbol. I don't think the availability of other players in the market affects the price.

> Everyone automatically defaults to assuming that your site is on .com

Yes, but is that new? People already assumed that and this is not caused by gTLDs, so it does not drive the value of .com domains up beyond what they already were.

For those TLDs that had certs, I’m curious: Should those certs have been revoked, since some/all of the associated domains no longer exist?

Why? I mean the certs are still valid, just for a domain that no longer exists on root DNS servers (You can still publish them to internal DNS). I mean, they'll expire and be non-renewable eventually anyway.

Until someone re-registers the TLD and can now MITM some internal traffic, if it is indeed used internally.

I can see the argument for invalidation, even if unlikely. The much more realistic scenario is where you get a cert for 2 years for any ordinary domain, even if your domain expires next month.

How could they - without private key? - By not revoking and having certificate transparency we rather can see if somebody else tries to take over the domain with a new cert.

With a new cert indeed. One would have to proactively look at transparency logs instead of retroactively, which afaik only the biggest companies on the planet (like Google) do, or maybe not even them.

Was the .boots TLD for the Boots chemists?

Companies are quick to register domains, I had to manage about 1200 or so at my last job, and migrate them to Route53.

Perhaps a manager thought it was a good idea, and IT said No!

The article says "you can find the letter publicly here" but doesn't provide a link. Typo? I'd like to some of the other "interesting reads."

The only purpose for a tld should be like .bank and have it cost $100,000 registration fee and similar verified stuff

Pay $185k for gTLD, get $100k per second level domain. Nice business sense.

And there's still be some random millionaire to register piggy.bank.

My personal opinion is that TLDs should be "generic"--.com for commercial, .org for organizations, country-specific TLDs, etc.--and that allowing private corporations to register TLDs for their own brands (like .xperia for instance) was a mistake

I'm amazed both that so many brands bought TLDs and that so many are rescinding them so soon, especially relatively tech-savvy ones like HTC.

I wish there was a TLD that corresponded to the last two letters of my surname, so I could register a domain and have an email like John@D.oe.

.es for the Jones’ :-)

My HN username is my surname... so naturally I snapped up https://nick.rw/

I wondered if they'd refuse it, for being close to "nic.rw" but they don't seem to use it.

Before I read the article, I thought it was .nato. Sort of a testament to how little I remember non big six or country code tlds.

Regarding Sony specifically, my first thought was "... and nothing of value was lost".

This is concerning: imagine you have a unique domain opportunity for your company in a smal, up-and-coming gTLD.

If you get it, yoj have to worry about the gTLD dying, and still get the .com

So you stay in .com with a sucky name

Per other comments there’s a recovery plan in place for public TLDs.

When I read it, the other comment said the fate was uncertain if the other company had issues - unless it is recursive, there is only 1 level of redudancy

ICANN has access to the escrow files and they will find someone to run it if necessary. There are dozens of registry service providers.

Full list of TLDs https://data.iana.org/TLD/tlds-alpha-by-domain.txt

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

Similar stuff

As a suggestion for the author, the omission of apostrophes in contractions is annoyingly distracting. Is this a new trend?

I really hope not.

$185k is the price for your own TLD? That sounds super cheap. I would have expected millions.

Back then it was expensive especially compared to just setting up a domain. Plus there are other rules too like having a support staff. The rules force applicants to effectively act like a registry company. Just to limit the number of applicants they put all sorts of annoying rules in the books. However companies with too much money in their hands did that and more. Google registered different names just for fun.

On the cryptocurrency equivalent: https://github.com/blockstack/blockstack-core/blob/master/do...

> It cost Blockstack PBC 40 BTC to create the .id namespace in 2015 (in transaction

$185, plus the infrastructure and know-how to run it.

I think the ability to setup BIND is easier to acquire than $185,000.

185,000 is cheaper than the cost of two full time employees, which is the minimum for 24/7/365 oncall.

I assume nobody is going to pay $185k for a hobby project.

I wouldn't be too sure about that. America's Cup and Formula One racing exist, so there are definitely expensive hobbies.

It really depends where your techs live. 185k is enough money to pay a 4 person team of highly skilled techs in south-eastern Europe for over one year, for example.

There's a lot more to running a TLD than just running DNS. That's only a small portion of it. Running a TLD is non-trivial and there's a reason most gTLDs are run by big players or hosted by contract by same.

Aren't most gTLDs hosted by only a few ISPs that also host some of the smaller ccTLDs? I'd imagine that the actual hosting costs are quite small if you don't have millions of domains with billions of DNS requests per second.

I'll run your TLD for $10 a month and make you a site to do registrations for $1000.

This is sufficient up until a few thousand domains. Of course that's not the common case, but the "plus infra and expertise" part is negligible compared to the ICANN fee if you just want a private gTLD.

In retrospect, it was probably far too little. ICANN didn't predict the demand for gTLD registrations; it's taken them six years to work through all the applications they received when the program opened in 2012.

That's the initial registration cost. If there are multiple applicants for it, it will go to auction.

For a popular gTLD, the auction can go into several million dollars. .shop, for instance, closed at $41.5M [1]

1. http://domainincite.com/19886-shop-gtld-sells-for-record-41-...

Wow, where does that money go to?

I thought ICANN was a non-profit? Is it the usual "yeah but we really needed $5000 meeting room chairs and our CEO needs a competitive $10m salary otherwise we can't keep him on"?

Maybe they're just hoarding it for now, and eventually will give it to internet nonprofits

> Wow, where does that money go to?

There was a comment thread about how the bidding process worked in 2016:

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

$185k is only for submission of application. Once you have the TLD, there's also mandatory recurring fee of approximately $25k/year + $0.25/domain transaction fee + setup and maintenance of infrastructure. My guess is that it would cost $50k-$100k/year to run it overall.

https://serverfault.com/questions/243316/can-i-create-a-top-...

I never understood why a TLD is a big deal in any real sense. If ICANN wanted they could make the whole web address a single string. No need for a separate TLD. It's like the filename's extension.

Not sure about the answer, but one thing that comes into my mind is about decentralization, in the sense of load balancing the DNS queries.

But then the DNS root servers would have to know every single domain in existence. The current system works because the higher level servers only need to know who below them in the hirarchy is responsible for the next subdomain.

How would you resolve a single string?

Replace hierarchical partitioning with keyspace partitioning (eg hash buckets). A fundamental difference in architecture, but so was GP's idea.

Because the current system with hundreds of TLDs is a multi-billion dollar industry.

in other news google is integrated in the browsers address bar, scientists are baffled how it managed to fit in such small space and how it got there.

Reply on news.ycombinator.com