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).
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.
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.
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?
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.
> 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.
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.
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?
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.
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 " 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.
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.
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.
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
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.
> 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.
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.
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.
> 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.
>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, 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.
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:
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 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"
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.)
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?
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).