I have a story on using weird/fishy/phishy TLDs: Recently my colleagues and I started collecting information on all the available compression methods for 3D Gaussian Splatting (3DGS, a popular method for 3d scene representation). There were quite a few works in the area with naming conflicts already, so I thought to give it a unique short name to refer to - and came up with “3dgs.zip”.
A few days later we started putting together a web page, and I noticed that .zip actually is available as a TLD. Impulsively I bought the domain, https://3dgs.zip/, launched it and printed it on a few shirts before heading off to a conference. Felt a bit weird that there is a .zip TLD, but I was in a rush and I didn’t ponder its existence any further.
But strange things started happening: setting up the domain for a GitHub page worked, but in the process downloaded a 0 Byte file called “3dgs.zip”, when submitting content one of the GitHub.com forms. And a few days later colleagues told me they had trouble accessing the site. After some DNS sleuthing and then some back-and-forth with our IT dept, it turned out that our organization has blocked the whole TLD - for every Windows user, out of phishing concerns of people being confused.
I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody; downloading a .zip might, which you can attach to any link name? But in any case I wasn’t able to find any .zip URL with a purpose, but lots of Reddit posts of angry sysadmins who bemoaned the influx of terrible TLDs with mostly phishing use and vowed to block them all. So they probably have a point in downright blocking the whole TLD.
Now I’m sitting here with my .zip url. Had to revert the page to use github.io, so people in my organization (and similarly thinking ones) would be able to access it. Guess I’m cured for a while, won’t be using any novelty TLDs anytime soon…
> I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody; downloading a .zip might, which you can attach to any link name?
Turn of all of your developer knowledge for a minute.
You click on a link "very-trustworthy-ceo-information.zip" in a mail, since you want to download this very important information from your CEO. Sure, your browser pops up, but it does that all the time so who cares, and then there is a file "very-trustworthy-ceo-information.zip" in your downloads folder. Native Outlook might usually open it in a different way usually, but who cares? OWA - you won't notice a difference in the UI at all. But anyway, important CEO information. Open the zip, open the PDF, oops your workstation is compromised.
If we turn our technical knowledge back on, it's rather simple. A user was phished to open a link to "https://very-trustworthy-ceo-information.zip". This returned with a file download, obviously called "very-trustworthy-ceo-information.zip", containing whatever I want to contain based off of IPs and whatever I can stuff into the link in a hidden fashion the average user won't note.
A lot of people would not be able to distinguish between https://foo.zip answering with a binary content type and naming the file foo.zip through content disposition headers and foo.zip coming from a trusted source.
And honestly, I would personally have to double-check what's going on there if it happened to me.
As a developer, the difference might be minimal, you see the http:// part.
For the average computer user, I'm guessing they don't "see" the http:// part. It looks like a link to an attachment in the email, so safer than a random URL.
> I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody; downloading a .zip might, which you can attach to any link name? But in any case I wasn’t able to find any .zip URL with a purpose, but lots of Reddit posts of angry sysadmins who bemoaned the influx of terrible TLDs with mostly phishing use and vowed to block them all. So they probably have a point in downright blocking the whole TLD.
The problem is auto-linkification. It is extremely common in forum posts or emails to refer to attached filenames. Most forum softwares or email clients are helpful it automatically turning obvious URLs (doesn't start with a protocol:// but ends in a .tld) into clickable links. Anybody's reference to a zip filename is now a clickable link, only waiting to be registered for phishing attempts.
That makes sense. Funnily enough I had kind of an inverse problem building the https://3dgs.zip/ landing page, or linking to the project from elsewhere - I’d point a link to the compression survey with the link text “survey.3dgs.zip”.
And had to have people point out to me that they don’t want to click on that, because they don’t want to download a big file.
The type of user who has email conversations about .COM files is the same type of user who will realize that the link was automatically created by someone's email client and have a laugh about it.
I don't know if you can say the same about zip files, an average user they might encounter someone mentioning a zip filename a handful of times in a year and they might click on the link expecting to get that zip file.
The thing is '.com' is relatively unknown. When was the last time you had a genuine .com file you needed to use?
And you're someone who's tech-savvy.
Most people are going to see ".com" and think "Website" not "Program". So if suddenly a .com file is downloaded there's at least a chance they might stop and wonder what's going on.
I run into this issue all the time - We get Bug bounty reports constantly because $SecurityResearcher put "example.com" into the "Company Name" field, and we sent them an email saying "Thanks for signing up. We hope you find $OurProduct useful at $CompanyName. "
When the email turns up in their Gmail inbox, Gmail "helpfully" turns the plain text "example.com" into a link to https://example.com - so $SecurityResearcher reports it to us as a vulnerability in our platform because "we" are linking to example.com - except we never did, and we have no way to tell Gmail, or Outlook, or any other platform to stop doing that.
Services we pay for, directly, also do this - Notion and Slack are two I can think of immediately. I have to fight them to stop turning my mention of some file into a link to a random domain. (e: Maybe Slack has stopped doing this, perhaps - in testing it didn't do automatic linkifying for messages to myself)
This was bad enough with .cs, .ts, .js., .json and so forth - but having a .zip link appear in the middle of documentation on how to do something with a zip file is a recipe for disaster.
I've had a document saying "please download package.zip from the build artifacts site" - which was then auto linked to https://package.zip - and anyone not paying attention might expect that it was a link to the build artifacts site.
The COM file exploit worked because it is relatively unknown. I remember a worm going around when I was in grad school where you'd get an e-mail with a link to https://giftcard.customerservice.savemoneyonanew.tv/amazon.c.... Users who had been through the phishing training would see the HTTPS at the beginning and the amazon.com at the end and know that this was a legitimate Amazon email. The e-mail instructed them to click the link and "open the PDF file". Users would click the link, down load the COM file, and the open the file, installing malware all over the machine and forwarding the worm to all their contacts.
Good point. I wonder what happens if i rename a malicious file into google.com and push it into ever AD user's desktop at a large corporation. Might not even make a difference that MS hides extensions by default.
Unsanitized web form mailers are a common source of spam mails, in particular if that form allows specifying an arbitrary email address to send the mail to. Essentially what the website owner meant to do was sending an innocent email (maybe for leaving feedback, or for a signup link), and the email text then gets mangled by the spammer in a way that you are seeing a link to product they want you to buy.
It is not a vulnerability in the sense that it leads to malicious code being executed, but it allows spammers to send their spam links through "reputable" email sources, increasing the likelihood that it will make it through spam filters.
Because some unsuspecting user may think we are linking them to some random site, even if we are not.
If that domain is "important-banking-info.zip" then people are less likely to be suspicious if their browser happens to download a file of the same name.
You're missing the point: he did not send an email with a link, he sent an email in plain text, no hyperlink, containing the ASCII characters "example.com", and the recipient's email client silently changed it into a hyperlink. And of course that doesn't just happen with "example.com"; it happens with any piece of plain text that the email client decides might be a URL, which includes many file names since many common file extensions are also TLDs. That is the security issue.
COM files have been used maliciously due to confusion with urls [0]. I think I've heard of antivirus software preventing COM files from being run because of this.
Although gp probably meant a PE executable [0] which (typically) start with a stub MZ executable telling DOS users to run it under Windows. Because of this they still have a MZ magic number.
I have recently been working on a command line tool and the windows version is called mz.exe. On Linux it is just 'mz', just a coincidence. I was concerned this name collision might cause problems, but that is fine.
It's not a new problem, but think about how many average computer users expect to be sent a ZIP file, vs how many of them expect to receive a TS, CS or COM file in their inbox.
I've seen it happening on GitHub, among others. Anyone that automatically imports an up-to-date list of all existing TLDs will fall into the same "trap".
I grabbed two .zip domain names that I knew were used frequently as filenames and set them up to return a zip with an html inside. The html tries to load a specific resource from the server to let it know the html was opened.
There are dozens of unique opens per week.
I'm very curious how an executable would do, but I'm not trying to cause any problems.
Ah that makes a lot more sense as an attack vector. Thanks for explaining! Indeed, checking a list of common .zip file names, most of them are registered domains. Uhhh.
> ILOVEYOU, sometimes referred to as the Love Bug or Loveletter, was a computer worm that infected over ten million Windows personal computers on and after 5 May 2000. It started spreading as an email message with the subject line "ILOVEYOU" and the attachment "LOVE-LETTER-FOR-YOU.TXT.vbs".
> I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody
I really apologize that our docs don't cover what to do in your situation. We move really fast with software to bring you the best experience possible and sometimes miss these things.
I'm the founder, John Smith, and I'll provide direct support here for you.
Just go in your browser and open the .zip archive to extract the file you need. You can use chrome, Internet Explorer, Firefox, or any other browser.
That's it! Opening the archive in that manner performed a reconfiguration on your exact system, so everything should now work on your end. Sorry about that snafu on our end.
I block .top and several other of the newer TLDs in SMTP. We get tons of spam from these TLDs, and we don't otherwise interact with those TLDs in our business.
Due to everything in a URL before the @ being interpreted as a username for basic authentication, this would result in the user navigating to https://example-project-v1.zip instead of to github.
Edit: Fortunately it seems like browsers have caught on to this trick
Yep, I checked other, established .zip domains. Finding one was quite a hard task, which gave me pause. I found a link shortener site on some Google promotional page for .zip (.zip is a Google-TLD). Accessing any .zip url was denied on the tested machines.
So this matches what IT told me and what the sister comments state here: some tool blocks the whole .zip TLD on the DNS level.
Tip: “nic.TLD” should always exist and will often be the first domain registered. It is operated by the domain’s registry. For example, see https://nic.zip.
So these type of filters work on massive lists that IT or Sec admin configure. Its not that they specifially blocked .zip but software like Umbrella, Zorus DNS etc have a filter for "phising domains" and that TLD is probably part of it. Blocks at the DNS level, its actually useful.
A big reason why .top is used so much is because it is so cheap. Phishers can rotate through many more domains using .top compared to other domains.
IMO this isn't a particularly big problem, it's cool to let people buy cheap domains. It also doesn't really save the phishers that much money. You aren't going to solve the problem by making domains more expensive, it might impact phishers' margins but they will continue phishing.
Stronger investigative and enforcement actions is something we can do.
But it's something that we don't stomach. I wonder why. I suppose it's because the modern business-centric Internet is centered on the ability to scam people out of money. Investigations and enforcements would open the floodgates to every "normal" business too.
> To prevent this conversation from being painfully abstract, let’s scope it to one particular type of fraud against one particular type of actor: the bad guy steals a payment credential, like a credit card number, and uses it to extract valuable goods or services from a business. This is an extremely common fraud, costing the world something like $10 to $20 billion a year, and yet it is actually fairly constrained relative to all types of fraud.
> This fraud is possible by design. The very best minds in government, the financial industry, the payments industry, and business have gotten together and decided that they want this fraud to be possible. That probably strikes you as an extraordinary claim, and yet it is true.
Indeed! However, I would add that this article focuses on fraud perpetrated against businesses. While it does give good perspective I'm actually more concerned about fraud perpetrated by internet businesses against consumers.
The problem is it's cross-border. Domestic law enforcement will almost always run into dead ends, maybe they'll catch some money mule that got conned into the job, but that's it.
The real dent would be to get India (for US scammers) and Turkey (for German scammers) to cooperate, the way to do it would be to threaten devastating sanctions ("clean up your scammer scenes, or else"), but that cannot be done as it is important for geopolitical reasons to appease India (a significant portion of the world's pharmaceutical base compounds originate from there, not to mention the Ukraine conflict) and Turkey (same reason, Ukraine conflict + about 2 million Syrian refugees that Erdogan already abused as a political weapon once).
Phishers benefit from low domain prices because they can churn them faster than you can investigate them. Scams are fast, investigation slow.
Worse, you investigate only to find that the scammer is out of your jurisdiction (which I submit is the #1 problem with “enforcement”) and there is very little you can do. Also, if they can churn domains quickly, the thread that connects them is harder to find, so you only have the remnants of one or two scam domains where there may be hundreds more by the same perpetrator.
I'm sure we're all open to suggestions. How would you go about punishing scammers in arbitrary jurisdictions while still allowing responsible individuals in arbitrary jurisdictions to buy domains?
We normally settle on "have an anti-abuse team and charge money for domains to pay for them" as the least-bad option, but if you have a better idea I'm all ears.
When we went to war against someone using our name in a recruitement scam, by the time they moved on, it seemed like they were up 5x on what it costs them in domains.
It's all heavily automated, and I suspect there's some credit card fraud involved too. I also reckon there's a few unscrupulous registrars that are helping them.
This is encouraging. We have a big tender (procurement) scam in our country, and I receive at least 10 different emails daily about fake procurement requests (the central gov database was either leaked, or the criminals are working in tandem with its administrators).
At times I have reported the impersonating domains, and I'd say that registrars have acted on under 5% of my complaints (within reasonable time). If they use a local domain name, it's easier to complain directly with our country's registry administrator.
My problem is often with registrars that are in random countries. It's encouraging that some action is being taken, and I think in future I should also lay complaints with ICANN.
> This is encouraging. We have a big tender (procurement) scam in our country, and I receive at least 10 different emails daily about fake procurement requests (the central gov database was either leaked, or the criminals are working in tandem with its administrators).
It's not just you, and I don't think it's targeted - I'm getting these messages as well on my personal email. This appears to be a major ongoing spam wave.
This really makes me wonder about the value of TLDs in general. Let’s say that “gmail” is a well known enough name that “gmail.com”, “gmail.org”, …, “gmail.top” should be reserved by default. If that’s the case, then the value of separate TLDs becomes interesting because two companies “abc.com” and “abc.top” would now have competing concerns. It seems like only small companies would then be open to phishing, and large ones would possibly be able to use trademark law across all TLDs. In fact large companies tend to try and reserve their name in all major TLDs.
I’m not really arguing for or against greater or fewer TLDs, but it does seem like an awkward situation.
If I could go back in time and change how domain names work, I would probably do 2 things:
1. Flip the order of parts, ex. com.ycombinator.news - this makes the whole URL big-endian, instead of the absurd middle-endian system we have now.
2. Either
a. drop the requirement to have TLDs at all - gmail would just be "https://google.mail/inbox" (including my first suggestion; "google" is the root domain), or perhaps just "https://gmail/inbox"
OR
b. actually commit to a small number of strictly-enforced TLDs - com is not the default, it requires a corporate entity to register, we probably push on having a single TLD for individual humans so ex. blogs tend to live under... actually the "name" TLD wasn't a terrible idea but I'm flexible on exact details of that TLD, just so there's only one of them. Second-levels like us or eu are fine but should again actually enforce having an entity in that country so almost nobody ends up using io or such.
I like reordering of the named components to big-endian, but just for reference, the current system dates back to the idea of “search domains”, which allows you to do things like “www” and that takes you to “www.example.com” because that is in your search or domain list in your stub resolver config. (This behavior can be skipped by using the fqdn with a dot at the end, “www.example.com.”)
I think moving to a new ordering of the name would then imply that we’d either need a different DNS or a new separator for specifying the reverse name ordering (that’s compatible with existing URL syntax).
Well, that's why this is purely a time-travel fantasy - I don't think we'll ever get a do-over:) And I can see the appeal to search domains, but I think in hindsight they pretty much failed, and what utility they have can be replaced with local or internal or something - "internal.www" can still be your intranet site, but now it's explicit. Or if we go with the other suggestion to force country TLDs then maybe it's fine for local DNS resolvers to do nonstandard TLDs, though I'm not super fond of that.
If we’re going to do some time travel, I’d also like to make the DNS packets easily versionable and add some space for additional version codes, the current extension mechanism with eDNS is quite cumbersome.
I like #1, but won't domain squatting become even more severe with #2.a?
Maybe there should be a regional prefix, e.g. us.gov, nz.gov, cn.gov.. and even this still comes with obvious issues and possible confusion. No silver bullets to be had, only tradeoffs.
That's a good point - I would be very much on board with mandating per-country TLDs, which is extra helpful because then you can deal with domain squatter through the legal system.
Not sure on what grounds nic.gov would then issue domains to disputed govts, coup d'états, ...
But it wouldn't seem to hard for each govt to claim .gov.tld (.gov.us - would also be easier to pass down e.g. .az.gov.us)
Fun fact, Switzerland's govt went for admin.ch (even pre .com boom times)
Yeah I like knowing that .us.gov is always a government site, and .edu is always an educational site, and there are governing bodies enforcing that policy - but for the rest, biz and net and com and io are cute, but completely unnecessary. I’d love to just go to https://gmail .
This "trust aspect" implied (or assured?) by certain TLDs, or for the non-US world by second-level domains under ccTLDs, has been, interestingly, completely missed by several countries in the early Internet days, including fairly large ones like e.g. Germany: Annoyingly, you cannot identify a federal agency or otherwise "official" website by its domain--no trailing .gov.de or the likes, it will alway be "just" ending in .de, which makes things like phishing but also deception (by implying a certain level of authority but in fact selling services from a private entity) unnecessarily easy. This is contrary to other countries' .gov.uk, .gv.at, .edu.au, etc. Although created for different reasons, I think, the Public Suffix List gives some indication of which countries enforce such namespaces (or did), see https://publicsuffix.org/list/
There is bund.de for the federal government, with e.g. the interior ministry (Bundesministerium des Innern) at bmi.bund.de. But personenstandsrecht.de has nothing in the domain name or even the whois to indicate that it really is part of the interior ministry as it claims. There are links to it from bmi.bund.de so presumably...
Here they do have such domains: .gc.ca for the Government of Canada, and .gouv.qc.ca for the Québec government. But annoyingly they both seem to be moving towards canada.ca and quebec.ca, respectively. There's even a whole .quebec TLD now that they could use, but no.
If you want trust having a corporate entity is not it, you can make them with no actual humans in the chain of trust, and you can easily register the same company name in multiple countries and cause havoc (as demonstrated with the EV certs)
It's not really about "trust" per se, more about forcing domains to be in the right TLD. Today my personal blog lives on a .com domain, which is absurd except that .com is de-facto the default. I aspire to a world where that doesn't happen, because all domains that aren't literally for a business are on something else, so com can't be a default.
(Corollary: If you create legal entities in multiple countries, I don't care if you have domains to match. I just want to avoid the current sillyness where people use the io TLD even they have zero association, even on paper, with the British Indian Ocean Territory (or whoever you believe should control that TLD))
#1 sounds like something hacky web browsers should introduce as an option for the address bar, as it's just aesthetics (I know it's not _just_ aesthetics, but close enough). Either to flip it, or perhaps even a regexp of some sort?
You could, but IMHO it's a terrible idea to add after the fact. Like, yeah if I had a time machine I would want to change it, but trying to change it today, even and perhaps especially in a cosmetic way, would just lead to confusion, ambiguity, and security problems.
Could go the other way. Make TLDs trivial to set up for anyone, so “gmail” becomes the TLD. Without changing how DNS resolution works I don’t think the root domain would be happy to handle that kind of traffic however.
In theory, Google could pay for the TLD ".google" so that... anything .google is reserved by default for google domains.
But this isn't going to work in practice; people don't read URLs so it doesn't matter. Second, for years there was this idea that all porn sites should be forced to go to a .xxx TLD so that it's easy to block, but that's impossible to legislate and / or enforce.
Though Google still doesn't use .google for much of anything a decade after establishing it, because it's confusing for normal users.
Their best known gimmick URL is the goo.gl shortener, which is actually the ccTLD for (not) Greece (actually Greenland) rather than a Google-specific one.
Things like "google.com" and "gmail.com" are established brands; switching that to "search.google" or "gmail.google" isn't really going to improve anything for anyone. I guess it's kinda cute for blog.google, but other than that it's pretty useless.
A bunch of companies bought these brand TLDs only to never use it and then abandon them a few years later. Probably a "zomg this is a new internets thing and if we don't do all the new internets things it we'll be left behind on the internets, and we can't be left behind on in the internets!!!11"-type affair.
> Their best known gimmick URL is the goo.gl shortener, which is actually the ccTLD for (not) Greece (actually Greenland) rather than a Google-specific one.
So odd, it must cost them approximately nothing to serve redirects for the static set of links they still had. Now they'll break links all over the web again.
One could almost wonder if the explosion of gTLDs in the 2010s has been pushed by registrars as they were seeing Big Money. In (my personal) retrospective, the value for Internet users and their actual usage is vanishingly small--compared to the downsides of massively increased phishing risks and, as you mentioned, the need for companies/brands to nowadays having to register (and pay for) a gazillion of irrelevant TLDs, merely for brand protection and abuse prevention.
Strange coincidence, moments ago I just received a phishing SMS about some bogus package that couldn't be delivered attempting to get me to visit a link on a ".top" address!
Strange that .co doesn't even show up in the list. I have a 3 letter .co similar to another .com domain and constantly receive customer id's and internal communications.
To be fair, it might be beneficial if they don't block them - I have never seen a legitimate use of the .top domain, so if that helps us get rid of the spam (by blocking the whole TLD on our systems) it's probably a win-win situation (?)
It's incredibly frustrating to hear such blanket statements about .top domains! I have a .top domain specifically to teach my son about DNS, certificates, Active Directory, and more. Just because some misuse the TLD doesn't mean all of us do. Is it really so shady and illegitimate to educate kids for free? Should we all just fork out $500 for a "legitimate" .new domain instead? Ridiculous! Why not go further and disallow all self-hosters, putting them in jail alongside pirates like Kim Dotcom or Assange?
There are whole countries where that is a high barrier, where that could be a many hours or days of work. It might not be a high barrier to you, but there are many millions to whom it is.
Literally just received some .top spam last night, nothing new there but curiously it was addressed to the mailing list for all students in my department.
Very sparse content too: Just a t.co link shortener address, which resolved to a .top domain (interestingly with an invalid https cert instead of going just with http). It was sent from an obviously compromised gmail address. Fellow students in other mailing lists got other shorteners with other domains, all resolving to the same russian ip address. Thats as far as I investigated.
Yup, I got several of those .top USPS scams. I did a whois history search, found that the domain (and about a dozen similar ones) were transferring to new registrars every several days. I guess that makes it more difficult for abuse reports to catch up to them. Clicked the link on purpose, and of course it wanted a credit card number. I gave a virtual card number with a spending limit of 0. Sure enough, several days later someone tried to use it to buy ads on Facebook.
While I don't disagree with warning .top, I notice in the report that .lol and .bond have higher "Phishing Domain Scores" than .top. Hopefully they got a nastygram, too.
They won't just outright terminate the whole tld just like that. They'll first try to find another registry willing to take over the zone.
But that poses another problem, assuming you haven't reg it for something like 10 years, suddenly it won't be as cheap anymore if the new registry taking it over decided to hike the fee.
Afaik .top is just really cheap for the 1st year. For subsequent renewal its around $4-5. More stable, less spammy, no looming problem of registry getting revoked .de .be .uk is around $4-5 too.
An organization like ICANN should not be concerned with the specific uses people are giving to their domain names.
Their mission should be to create a system that makes it convenient for actors to identify each other across the Internet, so that they can communicate arbitrary data. ICANN should be agnostic to the contents of the communications.
I generally don't disagree! But large-scale phishing is a threat to the integrity of the domain name system, so it is in ICANN's interest to crack down on it.
I've see tons of phishing from those domains.
Even the ones who eventually take down sites that I report, they don't look for other sites/domains from the same scammers or that have the same content, and they don't do anything to stop the same person from getting another domain and then putting the exact same content on it.
I shouldn't be hard for a company to identify most of these scammers. They are not subtle. Very basic automated checks to see what content is being served from new domains based on previously discovered phishing sites could catch a lot of it. Company's just aren't required by law to care so they don't.
Even big companies are terrible when it comes to phishing. I found out recently that for some google sites you can't even report the phishing site to Google without first signing into a google account. Why someone should have to hand over their personal info to Google in order to report a phishing site is beyond me. It's bad enough that Google refuses to respect RFC 2142 and accept reports at an abuse@ address. Internet standards exist to prevent exactly this kind of bullshit.
Daydream: Browsers and email programs are shipped with "Default Allow" lists, which include only the older & higher-quality TLD's. While users can add whatever TLD's they want to the lists, that default behavior destroys 99% of the value of new & crap-infested TLD's.
Per the article 0.2% of .com domains are phishing vs 4.2% of .top. Or put another way, if you have a .top domain it's about 17 times as likely to be phishing than a .com domain.
.com has the most phishing domains by virtue of by far being the biggest, not because they have looser controls or are less reliable.
Only if you select a random domain from a list of all .com or .top domains. No one does that of course. The chance a random .top (or .com) you encounter is a phishing domain isn't so easily calculated, depends on where you see it, etc.
Ate some cheese before dreaming: Google and MSFT (as maintainers of the dominant mail clients) start charging TLDs under the table to go on GMail/Outlook's "Default Allow" list, except, of course, the ones that Google administers
Why does that matter at all? If I go and create a bunch of legitimate .top domains, is it suddenly better somehow? No, it's still the first of the list, and .com is still second.
yes, precisely. if you and a bazillion other people do it so that the percentage goes down. it's the fact that scammers are glomming onto a trendy TLD ruins the reputation of that TLD. If the percentage of scam is higher in one TLD over another, people will consider it a TLD used for scams. Not sure where the logic breaks down here
> No, it's still the first of the list, and .com is still second.
also, what do you mean .com is second? it states that .top was second to .com
Because any action will have a negative impact on the legitimate sites and we want to maximize the effect while minimizing collateral damage.
It seems you’re saying if there’s a terrorist training camp with 10 terrorists and no bystanders in it, it would be unreasonable to drop a bomb on it unless we’re first willing to level the nearby city of a million people with 11 terrorists in it because it has more terrorists.
I already do this with NextDNS, I block all the "new" TLDs except for .io, .tv, and .ai because they're used for tech sites that are legitimate. I know that many organizations do the same, in fact it's mentioned in another comment.
> The warning comes amid the release of new findings that .top was the most common suffix in phishing websites over the past year, second only to domains ending in “.com.”
And this is why this is bullshit. Imagine them threatening to end .com over this. No? Then why bully others.
How these shady registry handle abuse is why i never use their dirt cheap tld for email. Most corporate firewall either outright reject them or blackhole into oblivion. Best case scenario is auto route to spam folder.
Might be useable as cheap domain used for hobby site, as personal dynamic dns domain but for email, nope.
I'd cough up $10 for .com .net .org and recent popular one the .me .io for best email deliverability instead of saving $5 and wondering whether my outgoing mail would arrive or not.
A few days later we started putting together a web page, and I noticed that .zip actually is available as a TLD. Impulsively I bought the domain, https://3dgs.zip/, launched it and printed it on a few shirts before heading off to a conference. Felt a bit weird that there is a .zip TLD, but I was in a rush and I didn’t ponder its existence any further.
But strange things started happening: setting up the domain for a GitHub page worked, but in the process downloaded a 0 Byte file called “3dgs.zip”, when submitting content one of the GitHub.com forms. And a few days later colleagues told me they had trouble accessing the site. After some DNS sleuthing and then some back-and-forth with our IT dept, it turned out that our organization has blocked the whole TLD - for every Windows user, out of phishing concerns of people being confused.
I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody; downloading a .zip might, which you can attach to any link name? But in any case I wasn’t able to find any .zip URL with a purpose, but lots of Reddit posts of angry sysadmins who bemoaned the influx of terrible TLDs with mostly phishing use and vowed to block them all. So they probably have a point in downright blocking the whole TLD.
Now I’m sitting here with my .zip url. Had to revert the page to use github.io, so people in my organization (and similarly thinking ones) would be able to access it. Guess I’m cured for a while, won’t be using any novelty TLDs anytime soon…