In fact, Donuts allows (allowed?) you to purchase the option to block other people registering `yourname.*` for all their tld's, at a lower price than actually getting the domains yourself.
Should major DNS servers just stop resolving TLDs that are not either the original six (com, net, org, edu, gov, mil) or a ccTLD?
Most spam comes from domains registered with these fake TLDs that ICANN has sponsored over the past decade, and apparently being an internationally recognized region isn't enough to stop a company named after the region from taking your quasi-ccTLD (if .eu exists, so can .amazon).
The term "cultural appropriation" is massively overused nowadays, but naming the company this, then years later stealing their TLD (and thus adding an entry to the long list of abuse that fake TLDs have caused) would be an appropriate use IMO.
The short answer is no, this will never happen. Root nameservers don't get to pick and choose which parts of the Internet get resolved; if they did, they'd quickly be replaced. As for recursive resolvers, none of the main ones would knowingly default to a broken configuration.
If you're using domain tlds as a heuristic strong enough to make blocking decisions your users are going to get wrecked because you don't have a real method of detecting phishing/malware sites.
Seriously, blacklisting tlds is not how to secure a network. If you can't trust your users and browsers enough to prevent phishing on a .io domain, they're gonna get phished on a .com and a .net. The existence of free dynamic dns services on both of those should be enough evidence for you to rethink that.
If your network is that sensitive you need to be whitelisting specific trusted IPs and blocking everything else. Your current approach to security is the kind of attitude that breaks the internet for nebulous gains. Do you block ipv6 too?
> If you're using domain tlds as a heuristic strong enough to make blocking decisions your users are going to get wrecked because you don't have a real method of detecting phishing/malware sites.
You say that like it is the only measure we employ to guard against malware and phishing. We have many other measures in place.
If this mechanism were causing more trouble than it was worth I'd be among the first to say we should ditch it.
> Oh, btw, if anyone reading this is one of the people making the decision to use a bunch of random domains in a TLD like that to host necessary chunks of your site or services required by your application, go to hell.
Tone aside, why do you object so sharply to anyone using a perfectly valid domain?
Because it makes using DNS filtering a pain. I may have whitelisted all of 'microsoft.com', for instance, and a bunch of '.ms' domains I've seen in the logs and know are microsoft's, but invariably they'll start using others and I won't know about it until a user complains and I have to go dig around in the logs and possibly the site code to figure out which bullshit domain needs to be whitelisted. It's even worse with everybody using '.io'. And why? to save a scant few bytes when referencing a 1MB block of JS?
You chose to use domain filtering. That's fine, but why should other people be obligated to arrange their parts of the internet in such a way that makes it easier for you to do that?
I'm not saying they should, other than that I can't think of a good reason they have to do it the way they do it and the way they do it inconveniences anyone trying to be proactive about controlling where users can visit.
They don't have to change, but I don't have to like what they're doing either.
You're doing the internet wrong and I feel sorry for your users. A tld makes no difference when a request to a resource could be to gstatic.com or to gstatic.io unless you're doing something as stupid as assuming the .com tld is magically safe from hosting malware and phishing sites.
>to save a scant few bytes when referencing a 1MB block of JS?
Presumably you are referring to the cookie with those "scant few bytes". I highly recommend you read up on the cdn caching implications of having all of your users request resources with cookies.
> You're doing the internet wrong and I feel sorry for your users. A tld makes no difference when a request to a resource could be to gstatic.com or to gstatic.io unless you're doing something as stupid as assuming the .com tld is magically safe from hosting malware and phishing sites.
I certainly don't think they're safe, but a much, much higher ratio of .com domains are A) actually used by our business, and B) legitimate.
> Presumably you are referring to the cookie with those "scant few bytes". I highly recommend you read up on the cdn caching implications of having all of your users request resources with cookies.
No, I'm referring to the domain using one of these TLDs. Why 'gstatic.com' instead of 'static.google.com' or some other subdomain of the primary?
>I certainly don't think they're safe, but a much, much higher ratio of .com domains are A) actually used by our business, and B) legitimate.
So what? It seems like you are confusing false positives with false negatives and using that to justify bad policy. There are probably 0.001% of .com domains your users need access to and 0.0001% of alt tlds. That's not a justification for whitelisting .com and blacklisting the others.
The policy hasn't inconvenienced users much at all, I'd know because I see any unblock requests, so why not? As I keep saying, it is just one of many safeguards in place against malware and phishing, we are not under the delusion that it is anything other than that.
If it were causing any significant friction in the business I'd be among the first to recommend stopping the practice.
> Why 'gstatic.com' instead of 'static.google.com' or some other subdomain of the primary?
Because they don't manually upload stuff hosted there, so in case some user-generated content hurts the reputation of the domain it's served on, it isn't their main domain that suffered the reputation hit.
What if I'm a guy who can't access the QA/staging version of his favorite pet open-source web project because they decided to host it at "[sitename].review"?
It doesn't technically prevent anyone from visiting the site, but my whole campus blocks every .review domain, so I have to tunnel out to another campus network (where they don't blindly follow all of ISAC's sometimes braindead suggestions) each and every time I want to verify that a change actually fixes the bug.
Isn't this a perfectly legitimate use of `.review`? Do you block this one too?
I've been asking for months. They also have blocked an entire /24 with some perfectly safe documentation on it, our InfoSec department says it came from our threat vendor, and our threat vendor says it came from one of our custom lists.
I got one thing unblocked successfully once, it took an entire week. Who are you protecting from what?
It seems to me like "turns out you can't trust the internet" is the right idea, but what exactly do you hope to accomplish with this block? You're not trying to make it so that... your users will think they can trust the internet?
No I'm not blaming you, I'm recognizing that InfoSec has more important fish to fry, than unblocking my pet projects that were a casualty of this garbage policy.
Maybe it's appropriate for your company, but it is not appropriate for a college campus or other larger organization with many salaried employees.
I understand not giving users rope to hang themselves with, but now I can only do this work at home. I don't like policies that cause tech workers to need to bring some of their work home with them.
It's a personal project (with some work-related applications, but putting that aside) — that shouldn't mean I can only work on it at home. But because of the overhead of making these requests, the only effective way for me to work on this stuff is now at home.
I don't like policies that result in people needing to bring more work home. I'd rather stay an hour late to get the thing some attention that it needs, and leave my computer in the desk drawer overnight. Policies like this sometimes make this impossible.
> Maybe it's appropriate for your company, but it is not appropriate for a college campus or other larger organization with many salaried employees.
Why do I care about what's appropriate for other orgs? My job is to deal with the needs of the one that pays my salary.
> I don't like policies that cause tech workers to need to bring some of their work home with them.
The policy has nothing to do with that. If you need it for work it will be unblocked in a timely fashion. If you need entire categories of things unblocked we can do that too, and just for your account.
You don't find it a bit strange you're talking about how this policy would block access to a personal project, but that in so doing it somehow causes you to have to bring work home? Which is it? Is it something you work on for work or is it a personal project?
> Why do I care about what's appropriate for other orgs?
You're here discussing your org, and I'm here discussing my org. Why are you posting on a public forum if you don't care about other people's problems ;) I'm not here to make it personally relevant for you and necessarily change your mind.
> You don't find it a bit strange you're talking about how this policy would block access to a personal project, but that in so doing it somehow causes you to have to bring work home? Which is it? Is it something you work on for work or is it a personal project?
It's a JavaScript app, and I'm a Rails developer without a lot of really strong JavaScript experience. I might need more JS experience for work. If I could take a class in this stuff, my work would probably pay for the tuition, and it would be tax-free. (But instead, I'm doing an Open Source project and as far as professional development goes, it's the same.)
I don't find it strange at all, I work on personal projects all the time, and some of that happens at work. Sometimes I like to choose my personal projects so that they will benefit my performance at work. In the community of practice related to this project, if something pops up on my Slack, and it will take two minutes to deal with it, I'm not going to tell them to wait until after hours; I'm bringing my actual work home with me on a regular basis (without overtime), so it would be unfair for me to say that the inverse can never happen.
Just to make it concrete, so you can see why it shouldn't bother my manager that I sometimes look at this project during working hours, the project is "Commits.to" - it's a time management / GTD tool for helping you be sure that you set a due date when something you said you'd do is important, and for holding you to getting done the things you said you were going to get done, by the due date or ASAP after. It's a beta project and the only people who are users are also developers. It is a community of practice.
Again I don't expect you to care about this project, but if my work is overtly saying "you need to go home if you want to work on that" I'm going to start looking for a different job. But they're not doing that. They've said it obliquely instead. (And since it's a college campus, they've said it to every student too... some of whom might actually live on campus.) So as we're all very busy, and I don't need to work on this at work, I've just let it slide instead of marching into InfoSec with a list of demands.
But the net effect is, sometimes when I want to do a quick thing for this personal project I'm working on, instead of spending the 5 minutes and getting it over with, I have to write it down and remember to bring it home instead. It's a net productivity loss, and I don't think that was anyone's intentional goal, but it was an effect of the (garbage, IMHO) policy.
I was criticizing the practice of using a bunch of domain names with vanity TLDs when there was a perfectly good domain sites could be using. I was criticized for this practice by you and others. It is unreasonable to criticize my companies use of the practice and justify that criticism with descriptions of how the practice would apply to other orgs.
Hey buddy, we're just having a discussion on the internet about our pet peeves, there's nothing personal about it.
You are perfectly justified in _not using_ the domains, because there are people like you out there who will block the use. This is my major contribution to the discussion.
But you must understand my plight, since in my view you are part of the problem. You don't just _not use_ the domains, you _actively block the use_. The research I found was that yes, most of these domains were registered for spammy purposes back when the new TLDs were new, in say 2015. So it was recommended to block them at an organizational level (by several prominent, well-respected neutral ISAC and other groups, who were very short-sighted about it IMHO).
Since then, several years have gone by and as you cited, many organizations are using them now, but you (and others) persist in blocking their legitimate uses with a blanket ban.
And as long as you and people like you remain, that continue blocking them by default, so shall they remain mostly spammy, since nobody can register them and expect to use them for anything important, without this grief.
If it were simpler I'd be all for blocking most of the worlds IP addresses since we only do business in the continental US. Sadly, maintaining a list of IP blocks is more trouble than it is worth.
You'll find that lots of ccTLDs have worse rates of abuse than many of the new gTLDs. It mostly comes down to domain price. TLDs that are cheap for the first year tend to have the highest rates of abuse.
Not that I agree with the idea of blocking entire TLDs to prevent abuse, but if you are, at least do it correctly.
All I can say is that it doesn't cause much friction with our users, or else I would be pushing to change the policy. Can't imagine what you'd be doing for our company that would require all this access. Maybe you're just entitled?
No, I'm with CydeWeys, it's not entitled we're just glad we don't work for you! :)
Just because your customers don't come from these countries, doesn't mean your vendors (and source code for important infrastructure) won't. Doesn't this seem a little bit even possibly xenophobic?
I understand you'll make exceptions in cases where the use is legitimate, and I don't know how large your organization is, but I would be worried that there are going to be missed opportunities because they're not going to come to me, if I was in your shoes.
They're just going to say "oh well," then move on and use something inferior that comes from inside of the bubble.
> No, I'm with CydeWeys, it's not entitled we're just glad we don't work for you! :)
Good news, nobody does. I work for someone else, nobody works under me.
> Just because your customers don't come from these countries, doesn't mean your vendors (and source code for important infrastructure) won't. Doesn't this seem a little bit even possibly xenophobic?
It doesn't, or they'd be whitelisted. And no, it isn't at all xenophobic. Hell, .us may be blacklisted, I'd have to check. We'd blacklist by default any TLD that's unlikely to be required. If it turns out we were wrong, we either whitelist specific domains or an entire TLD if it keeps coming up. It isn't rocket science.
> I understand you'll make exceptions in cases where the use is legitimate, and I don't know how large your organization is, but I would be worried that there are going to be missed opportunities because they're not going to come to me, if I was in your shoes.
We're not a software business. There would be significant logistical and legal barriers to overcome even if there were some potential whale of a customer in, say, Spain. If the people running the company had any realistic expectation that this policy would cost them a customer I can assure you they'd never have let it be implemented. Hell, I would have recommended against it if that were the case.
I get your rhetorical point, but at this time the floodgates of shitty new gTLD domains have been open too long, there are hundreds of them now. Just a cash cow for ICANN.
> In a report published in December 2009 by McAfee, "Mapping the Mal Web - The world's riskiest domain", .cm was reportedly the riskiest domain in the world, with 36.7% of the sites posing a security risk to PCs
I don't agree with the previous comment at all, I'm happy to have more TLDs, but a report from 2009, before creating new ones really opened up, isn't useful.
It would also be useful to know how many domains in the TLD or what the distribution of requests is over all TLDs. Yes, .com should have a large percentage because there are so many domains registered in that TLD, but if 20% of the .amazon domains are spam/malware/phishing then a savvy admin will block by default and just whitelist the small number of exceptions.
I am less concerned about spam management than I am of phishing sites and the like. Email from bogus tlds is of little concern because it will hit the spam bucket just like everything else, but if you do a DNS lookup on one of these joke tlds you can expect a high probability of having the request filtered.
There is also .om for Oman. But I don't see how either of these domains are "risky", at least not anywhere as bad as subdomains of the pattern [actual].com.[impersonator].com
I'm inclined to think '.cm' is top because of its visual similarity to '.com' so it can be used to fool easier, rather than any reasons related to the country itself.
I think it’s fine to have generic .com, .org, .net and so on. These are useful given there are multinational companies, organisations, etc. so there’s no reason to mess with that.
What I think is really inappropriate is that .gov, .edu and .mil are US-only. These should either be opened up to all countries, or phased out.
I think for these particular ones, phasing out would be the best way - i.e, no new registrations, every domain owner gets matching (edu,mil,gov).us domains, and then requiring them to only serve redirects to the new domains and not content after a few months.
"Amazon tried to entice Latin American officials with $5m in Kindles, AWS credits for .amazon -
Brazil, Peru snub cheap gifts, refuse to unblock dot-word"
I think a better example of this new policy is Google getting "docs.new". What about onedrive or other companies. ICANN should never have started down this path and opened this can of worms.
Other than having a .com because most folks will just add a .com at the end of the name when URLing, what are the other practical use cases for having a TLD anyway?
Here in Russia s/com/ru/, and .su zone had a 5% of active sites in russian for a decade. And .xn--p1ai is the biggest IDN ccTLD by number of second-level domains.
Point is, language/culture/country-based differentiation is still a use case.
I think they should only offer these domains to companies who demonstrate a commitment to protecting the Amazon environmentally. It'd be a crying shame for logging companies to have .amazon domains for example.
Can't recall where I saw it but someone created a visual comparison of volume / time (ie, throughput) of the Amazon River vs Amazon.com's delivery of physical goods. The river won by a lot, but they were on the same scale.
You want amazon? You’re a bad guy.
You don’t want amazon? Someone else gets it, phishes your users, you’re a bad guy.
It’s kind of a protection racket...
There’s a whole lot about this whole thing going at with the ICAAN I’m not comfortable with.