Dumb question: Why do we need generic TLDs at all? Why can't I associate any unique name I want with my IP addresses in my DNS records? Why shouldn't we use "https://ycombinator"?
Is it due only to the legacy of DNS? I suspect I'm missing something obvious, but even a quick search didn't reveal the answer.
Due to the hierarchy of dns you can ask to a root server who handles .com, then to that server who handles google.com, then to that Google server, who handles mail.google.com, and then you can connect to it. If you allow anything to be a TLD the root servers need to know about everything, which isn't really feasible
> If you allow anything to be a TLD the root servers need to know about everything, which isn't really feasible
I wonder about that: The number of TLDs in my scenario would be approximately equal to the number of user-registered[0] domains now.
The .com root servers already need to know a large fraction of all 'user-registered' domains, and will need to scale to a much larger set of data as the number of domains grows.
Therefore, I expect that scaling to all 'user-registered' domains wouldn't exceed the root servers' capacity.
[0] I can't think of the technical term at the moment, but domains such as ycombinator.com, bbc.co.uk, ox.ac.uk, etc. Second-level isn't quite correct (see the .uk examples), and I know parsing the user-registered part is a bit of a challenge; see https://publicsuffix.org.
But the conventional wisdom is that you should let someone else run nameservers and give them your IP address. As such, they get to make the rules. Not to mention they also are often in the business of selling domain name registrations under those TLDs you wish to do without.
Further, assuming you plan to use your domain name in a web browser, browser authors can make a second set of rules about what domain names are "acceptable". They can block your TLD agnostic domain name. No DNS is involved.
You could edit the browser source code to modify any such rules and recompile. But as with nameservers, the conventional wisdom is to let someone else, e.g., a company, write the web browser; users are not meant to edit the source code.
You can do many "unconventional" things with DNS. But maybe your question is not what you can do, but why the third parties who control DNS for the masses do not do these things?
Traditionally, that refers to the computer named "ycombinator" on your local network, and the domain directed the networking stack to some external network. Eventually, the community recognized that everyone should agree on what name to use for each network, and domain registries were born, along with the traditional TLDs.
Internet upon its creation was subdivided into sections or tld. The ownership of each section was handed to a different entity. The entity managed all of the subnames on its section. And so began the modern tld system.
The management of the subnames on each tld is still given to one entity. For example, verisign manages the .com TLD.
So in order to create new TLDs you need managers to step up. That's true for even country level domains.
So your question would evolve to if an entity can apply for and manage it's own tld. Well, icann did open this up and had some heavy requirements for TLD managers.
If Named Data then no need to trust the server, because trust the data. The data is signed. Signed data is trusted and doesn't care what path it takes to go where it's wanted.
The same problem holds; what if multiple people sign data under the same namespace? You need some way of mapping a name to a single public key, so that you can check the signature. That's equivalent to a nameserver.
Is it due only to the legacy of DNS? I suspect I'm missing something obvious, but even a quick search didn't reveal the answer.