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.
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.
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?
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 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.
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..
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?
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.
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.
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.
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.)
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
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.
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.
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.
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 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.
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.
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)
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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'...
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.
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?
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...
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.
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.
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.
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
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
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.
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"?
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.
$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.
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.
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.
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.
https://www.spamhaus.org/statistics/tlds/