.zip is now available as a TLD | Hacker News Reader

.zip is now available as a TLD

twitter.com

61 pointspartiallypro96 comments

How long until .exe, .app, .apk, and .ipa follow?

I don't really get why you'd pick a popular file extension as a TLD. It was bad enough when .java got registered, though that's worse because Oracle decided that the name of an island inhabiting over 150 million people was actually theirs to register (and ICANN want along with it).

didn't know about the .java tld. maybe because tld are assigned to countries and not provinces?

gTLDs are not assigned to countries.

TLDs have been assigned to cities (.amsterdam, .london, .nyc) and provinces (.frl).

They're not ccTLDs though, but TLDs bought by a registrar.

> They're not ccTLDs though, but TLDs bought by a registrar.

Registry, not registrar.

> How long until .exe, .app, .apk, and .ipa follow?

Well, we’ve had .com, for a while (though its no longer that popular as a file extension, but…), so…

I can't imagine those would ever be made available.

Fortunately, .zip seems less worrisome from a security perspective -- you don't execute a zip file. (Unless I'm missing where clicking on .zip files is an intermediary step in a common exploit?)

It's more just confusing from a usability perspective. Like, I don't want domains ending in .jpg or .mp4 or .doc or .txt either, you know? It's a benefit to be able to look at a string and usually be able to reason with high confidence whether it's a domain name or filename.

It definitely feels weird to me.

Devil's advocate -- what exactly is the attack vector here, even for TLDs that share names with executable file extensions? .com already exists, the biggest one of them all, and that doesn't seem to cause problems?

https://en.wikipedia.org/wiki/COM_file

https://twitter.com/_mg_/status/1658528430588317696?s=46&t=-...

The reason .java was approved is because the ISO-3166 designation is the Indonesian "Jawa" rather than the English "Java".[1]

Thinking about this, I can follow their reasoning, although I do find it a little bit too much following the letter of the rule rather than the spirit and perhaps some more thinking might have been prudent.

On the other hand, do we really want to give a special status to English? Using the local language seems to make sense to me – after all, Indonesian people will want to type "gojek.jawa" and not "gojek.java". And there are some questions: should we also consider placenames in Spanish and other widely used languages? Is a small town of 100 residents enough to prevent registration? etc.

[1]: https://gtldcomment.icann.org/applicationcomment/commentdeta...

Perhaps .java and other English-language equivalents of domestic-language gTLDs should be reserved to act as proxies for the underlying domestic-language gTLD. I.e. the root nameservers should direct requests for .java to the same nameservers responsible for .jawa; and the nameservers for .jawa should be required to respond to queries for any record of A.B.C.D.java. by rewriting the request to be for A.B.C.D.jawa., and then resolving that, rather than treating it as a separate zone.

Domain owners of domains in gTLDs like .jawa would only get one DNS zone file to control — the canonical one — but they'd be free to do something different on the application layer in response to differing e.g. TLS SNI in the request. (So if they're running a webserver on A.B.C.D.{jawa,java}, then they could make the .java version do an HTTP redirect to the .jawa version; or make both serve the same page, but with a rel="canonical" header pointing to the .jawa version, etc.)

Personally, I feel like it'd make sense to add all sorts of proxy gTLDs for every existing two-letter ccTLD, both in their own language and in other languages. So e.g. the .de ccTLD could have both .deutschland and .germany acting as proxy gTLDs, where a domain owner who registers a .de domain is "getting" those others as well, for free.

This would obey the Principle of Least Surprise for both people visiting domains, and people buying domains: if you own example.de, and a .germany gTLD were to exist, then it would be surprising if you didn't also own example.germany, since the two TLDs serve the same purpose.

This seems quite complex and confusing. Potentially also a security risk:

1. gojek.jawa exists and is a valid domain; gojek.java doesn't exist.

2. Some people get used to typing gojek.java, and this is fine because it "just works".

3. A malicious actor registers gojek.java

4. Oh noes!

Or am I missing something?

I said that the alternate-version gTLDs should be reserved for use as proxies. Nobody would be able to register them. Mirroring their canonical TLD would be the only thing they do.

There would be no gojek.java that would be possible to register; no registrar for .java; no nameservers that hold zone files with .java in their names.

There would only be the registrars and nameservers for the canonical TLD .jawa; where these (and other) nameservers would know a TLD canonicalization map [which would be something like the Public Suffix List] that rewrites all .java requests they receive to .jawa requests before the rest of DNS resolution logic takes place.

You'd register gojek.jawa, point its NS records at e.g. Cloudflare, and set up a Cloudflare zone for gojek.jawa containing an A record for gojek.jawa pointing to some IP.

The registrar would publish a zone file to the .jawa nameserver saying that gojek.jawa has NS records pointing to Cloudflare. You'd be able to see these NS records by asking the .jawa TLD nameserver for NS for gojek.jawa or gojek.java. (Why would you be asking the .jawa nameserver for .java records? Because the root nameservers would point to the .jawa nameserver for both "java." and "jawa.")

Cloudflare would publish a zone file to its own nameservers saying that gojek.jawa has A record with value W.X.Y.Z. You'd see this response whether querying Cloudflare's nameserver about gojek.jawa or gojek.java. (Because it also understands the TLD canonicalization mapping.)

There would be, in effect, no "materialized" or "reified" .java TLD. It would only exist as 1. an entry in the canonicalization mapping, and 2. an NS record in the root zone.

Ah right; I misunderstood and thought you meant "proxy if a domain doesn't exist".

I don't know if there's even any way to take .java away from Oracle so this entire thing might be moot, but there are some others that just have two TLDs for the same thing: .wales/.cymru (Cymru being Wales in the Welsh language), .cologne/.koeln (Koeln being German for Cologne), .barcelona/.bcn, .istanbul/.ist – arguably a bit uglier, but simpler to implement as no software updates are needed anywhere.

> arguably a bit uglier, but simpler to implement as no software updates are needed anywhere.

My point was that the way we're currently doing this is a horrible idea, because if you buy one domain you don't own the other, and therefore someone can squat on it, and therefore you are basically blackmailed by that into buying O(N) domains even though you only wanted to market one of them.

> On the other hand, do we really want to give a special status to English

We already do and I wish it would stop. You can't call yourself an ace in German in plenty of services because the same letters happen to refer to the human bottom in English.

> On the other hand, do we really want to give a special status to English?

Yes. English is the lingua franca of the computing age. Having a common reference language is a good thing even if not popular with the professionally outraged.

.app has been out.

Its five year anniversary is this month, in fact. https://blog.google/products/registry/5-apps-you-should-know...

After we combined the search bar and address bar some queries turn into page loads. So before typing example.zip would perform a search, but now it leaks the terms out to my DNS server, usually in plaintext.

For TLDs that match popular file extensions, this risk is pretty high.

Enabling separate search and URL fields is one of the first things I do when setting up a browser, along with defaulting to DDG search.

Why would it leak terms to the DNS in plaintext? Aren't most DNS servers encrypted between the client and server? I know that's true for DNS over HTTPS but I thought it was generally true as well these days

hahaha no. You have to go out of your way to use DNS-over-HTTPs or DNSSEC.

DNSSEC only provides signatures, it doesn't encrypt your queries.

How much you need to go out if your way depends. Firefox enables DoH by default in some areas, for example. Windows and Chrome will try to use it if your DNS server of choice supports it (i.e. if you've set up 1.1.1.1 or 8.8.8.8).

Android has Private DNS enabled by default, I believe. Some manufacturers may turn it off, I don't remember the setting my devices shipped with.

Oh! I always thought DNSSEC was encrypted, thanks for the correction

I believe DoH rollout is still ongoing. The last I see from Chrome is https://blog.chromium.org/2020/05/a-safer-and-more-private-b... and the last I see from Firefox is https://support.mozilla.org/en-US/kb/firefox-dns-over-https Those changes are driving up the adoption rate, but it's not complete.

I suspect most DNS is still unencrypted at this point, but I can't confirm.

Some of the old ccTLDs are offenders too. Too many times have I pasted a shell script's file name into the url bar and it starts loading a search result page.

For more sensitive use cases a better default will disabling search in the "omnibar" altogether like in ungoogled-chromium.

I would say it's the other way around, no? Common file extensions are offenders for copying ccTLDs that already existed.

The .sh ccTLD was registered in 1997[1]. I can't quickly find a reference for when the .sh file extension was first used, but I'd be surprised if it weren't older.

[1]: https://www.iana.org/domains/root/db/sh.html

Yes, I was more talking about the older ccTLDs for more real countries.

For these situations, it is useful to type

  ?example.zip

and force the browser to perform a search.

Wow, here I am having used Chrome and Firefox for a decade and a half, and I never knew the "?" trick.

That is super-useful, thanks.

Why not "g example.zip"? It is faster to type, also configurable what to do.

Or ctrl+e, ctrl+v, if your left hand is there.

I don't understand. "?" already works. "g" doesn't do anything, no matter if I follow it with a space or a tab. It's also not faster to type, since "?" doesn't need to be followed by whitespace.

g and space are both home finger keys though. Question mark is not nearly so easy to type. I think "g " might win out.

To get it to work I think you need to configure g as a bookmark shortcut though, so it's not built-in.

In Chrome, you can change the shortcut for each search engine in the settings. The default shortcut for google is "google.com".

"g " does whatever you want, and it has cross browser support. "?" does whatever the browser you use happen to do. Typing-wise you may be right, it depends how do you type, or where are your hands.

Nice. I usually just wrap it in double quotes, but this is slightly easier.

I also like to use ctrl+K to search from the address bar.

It's nice because usually I use ctrl+L to type in the address bar and that's a similar shortcut for times when my search looks like a URL.

Or just type a space in the query (example zip). Search engines know what you mean by that.

I just tried to buy some and the prices varied wildly depending on how common the words might be (from $30/year to $750/year).

Is this a common thing, where registrars (like Google) basically are now acting like squatters for domains that are actually open?

Yes, most newer TLDs have "premium domain" pricing.

So why is ICANN ok with this? I suspect enough people dangled tons of money in front of them.

Yes I understand that it's likely that squatters would've taken this instead. But instead of coming up with a solution for that (like, if you don't use it for X amount of time, then it's lost), they instead decided "why don't we just take that money"

ICANN does not dictate pricing on nTLDs. ICANN gets an (very large) initial fee to approve the nTLD and gets a small cut of every domain sold, while the registry is free to set their own pricing and terms.

>if you don't use it for X amount of time, then it's lost

Okay, now come up with a definition of "use" that effectively eliminates squatting-for-profit that doesn't also eliminate legitimate uses for having multiple domains that don't look like they're "being used"

> Yes I understand that it's likely that squatters would've taken this instead.

The squatters are actually better in some cases. If they're selling a non-premium domain that you can renew cheaply, the up front price can be more tolerable than the long term cost of a premium domain.

It looks like the premium domains for .zip are about $550 USD on Porkbun. I'd way rather pay $5k up front for a .com compared to $5.5k over 10 years for a .zip.

I thought that most new-age tld‘s are operated by scammers/squatters

I was curious about this as well. It seems like arbitrary short names were “premium” without any value in their meaning.

Well, .dev domain has HSTS enabled to all subdomains. And there won't be even a hit to port 80 - it goes straight HTTPS by browser because of preload list. So you can't have non-HTTPS site on .dev domain visited by a browser. Thats some value.

You can serve anti-HSTS headers if you really want to serve HTTP, but you'll need to serve HTTPS for the initial page loads.

I was able to pick up https://badday.mov/ for regular price. :D

Who knew registrars would go full on rent-seeking like this? So unpredictable.

Registries, not registrars. And yes, it’s extremely common with most TLDs. They define multiple premium levels depending on the « value » of a domain.

It’s a business, nothing new under the sun.

> Is this a common thing, where registrars (like Google) basically are now acting like squatters for domains that are actually open?

Yes, but it's kind of surprising to see Google doing it. I'm a bit shocked TBH. I always considered Charleston Road Registry (Google) to be "safe" in the context of not screwing users, but I guess that was a mistake.

Most of the ngTLD registries are run by business and finance people, not product people. IMO the only thing they understand is price discrimination. They're run by the kind of people that would see a dollar bill blowing in the wind and chase it off a cliff.

The biggest thing I don't want when registering a domain or managing a brand is uncertainty. However, the registries and ICANN have proven via their actions that registrants are secondary to the registries. The registries can, have, and will change pricing on existing registrants. ICANN allows it as long as it's a uniform pricing change (ie: everyone gets screwed equally).

Out of the original CNOBI (com, net, org, biz, info) domains I think .com and .net are the only ones with price controls left. I'm sure there will be effort to remove those in a short sighted money grab.

As-is, the only safe TLD is .com. It's the only one with enough registrants to resist getting screwed. All of the new TLDs are a huge risk because you have almost no rights as a registrant.

It's sad too. I think the new TLDs could be awesome for the internet if the registries were run by product people who understood that registrants need stability and long term guarantees. If anything they should be lobbying ICANN for price controls because it makes their product better for the customer. I'm sure Ethos Capital will get right on that [1]. Lol.

> In January 2021, Ethos Capital acquired Donuts after their failed bid to gain control over the .org internet domain.

I think Donuts is by far the largest TLD owner, so that gives an idea of how trustworthy the whole industry is IMO.

If you sell unique, valuable items way below their value then all you’re doing is creating a secondary market for scalpers/squatters to thrive, which is terrible for everyone. Having premium domains means they can be priced correctly, killing squatting, bringing more revenue to the registrar, and actually lowering prices for users that are not using automated bots at scale. Domain squatting is rent-seeking, this reduces that activity.

You don't think .org is safe?

Even after ethos was ran out of town by the California AG?

Arguably, the .org registrants are better connected than the typical .com registrants.

This is unfortunate. I hope apps don't interpret file names as domain names, much less as directions to an http server

I guess this could be a more common issue with zip, but any TLD could also be a file extension so in that sense this isn't a new problem

Yes, but TLDs like this increase the attack surface of the system, making it easier for bad actors to exploit bugs in networked software or craft phishing-style attacks (including more opportunities for typosquatting). While com/net/org/country only was too spartan, I see the modern TLD free-for-all as a Bad Thing.

Is this actually a permitted use of the TLDs?

I guess the answer is a de-facto ‘yes, because it’s done now and we’d have to revoke registrations to undo it, which is too unpalatable’, but at least some of these are not in accordance with the TLD applications:

From https://icannwiki.org/.nexus:

The mission of the proposed gTLD, .nexus, is to provide a dedicated domain space in which Google can enact second-level domains that relate to Nexus-related products and⁄or services. Specifically, the new gTLD will provide Google with greater ability to categorize its Nexus offerings online, and in-turn provide a more recognizable, branded, trusted web space to the general Internet population.

…

Charleston Road Registry believes that given its intended use by Google, the .nexus gTLD will best add value to the gTLD space by remaining completely closed for the sole use of Google.

…

Second-level domain names within the proposed gTLD are intended for registration and use by Google only, and domain names under the new gTLD will not be available to the general public for purchase, sale, or registration. As such, Charleston Road Registry intends to apply for an exemption to the ICANN Registry Operator Code of Conduct as Google is intended to be the sole registrar and registrant.

Fun fact about the application details is that they aren't binding, and ICANN actually encourages taking formerly closed domains and opening them up for general registration.

I can't help but feel like the United States letting ICANN become an international body is the reason for this.

There are 8: .dad, .phd, .prof, .esq, .foo, .zip, .mov and .nexus

.av1 .mp4 when?

I want .rar or .mkv to happen and have it be conquered by warez groups :3

Someone already snapped up torment(dot)nexus.

Looks like the next Metaverse will get more exciting.

Metaverse? That's so last year.

AI in the other hand...

I know, but I posted about .zip because it's a common file extension (you could make an argument for .mov as well though that's dated.) This seems to break name spaces and could be a nightmare for OpSec and also break local search in some instances (with Windows, OSX, etc launching the TLD instead of the file.) Seems like a bad thing which bad actors will take full advantage of.

I can picture a file.zip squatting site that shows a windows-styled "unzipping" window and says "file is protected, please enter <whatever information> here to unlock"

or .com...

Someone tell Sonatype about ‘.nexus’

Related ongoing thread:

The .zip TLD sucks - https://news.ycombinator.com/item?id=35920336 - May 2023 (254 comments)

Well, that seems like a bad idea. Out of curiosity, does anyone know what happens if I have: `<a href="google.zip">Link</a>`?

Will the browser navigate to an external site or will it try to download google.zip?

You need a http:// or https:// prefix to tell the browser to navitage to another site, otherwise the request defaults to being a relative path.

I see, I assume that is true for all TLDs? (Can you tell I don't do much web front-end lol)

If it's a relative path then it's not a TLD. It's only a TLD when it's part of a domain name.

Yes.

Or just //

This behavior doesn't depend on TLDs. A href will be to the local origin unless it starts with a protocol ("https://example.com") or two slashes (protocol-relative link, like "//example.com"). (The rest of the rules are that if an href starts with a single slash, then it will be a domain-relative link, otherwise it will be relative to the current URL's path.)

It should try to download `google.zip` relative to your current URL.

For it to be a domain name it should at minimal be href="//google.zip", where the browser will inherit your current protocol.

It will get resolved relative to the current location.

You would need (at a minimum) '//google.zip' to trigger a cross-domain link

Tried to grab nudes.zip... As always, someone else did it first.

ah, unzip.zip is taken.

so is un.zip

so are winrar.zip and g.zip

un.zip isn't registered, it's a globally reserved term on all gTLDs for the United Nations. You can query WHOIS/RDAP to see that it's not registered.

That's something I never knew existed. I found a list here: https://www.icann.org/sites/default/files/packages/reserved-...

Sorry, i might be being stupid, but this doesnt seem to be the case for me via who.is and its not on the icann list in the other child comment, any ideas?

bitcoin.zip is available for only $1100 / year. Scamming is high margin, so I bet a scammer will buy that from the scammers for scamming.

bitcoin-wallet.zip is available for <$15 / year if you're scamming on a budget.

I'd love a .api TLD

Would be great for bee enthusiasts

so can we assume this is a honeypot TLD?

this tweet suggest that google was like "boop I made a TLD" but it really happens with icann, right?

to be fair, .com also used to be a common file name extension..

sighun.zip

why is .zip a bad idea?

Reply on news.ycombinator.com