# A short history of namespaces outside the DNS
> Alternative roots, early blockchain naming and today's onchain registries: what each attempt tried, why most stayed marginal, and what changed.
Source: https://hush.partners/history-of-namespaces-outside-the-dns
Category: Market & ICANN
Published by Hush Partners.
---
The DNS is not the only namespace the internet has ever had. Since the early commercial internet, groups of engineers, idealists and entrepreneurs have tried to operate naming systems outside the structure that ICANN coordinates. Most of those attempts accumulated registrations without accumulating users, and faded. The ones that persisted stayed marginal enough that most internet professionals never noticed them.
That history is worth knowing. Onchain TLDs attract reasonable skepticism, and some of that skepticism is inherited from the failures of earlier alternative namespaces. This article works through each generation of alternative naming, identifies what limited it, and then asks what is different about the latest one. A brand owner or legal team that understands this arc can assess claims about onchain namespaces soberly, without either dismissing them too fast or accepting them uncritically.
By the end, you will be able to place any onchain naming system in a longer story, identify the structural problems that have persisted across every generation, and judge which of those problems have been addressed and which have not.
## Why people build names outside the DNS
Every alternative namespace starts from the same observation: the DNS is coordinated from one place. ICANN's processes decide which TLDs exist. Registries and registrars set the terms and prices on which names are sold. Courts and authorities can, in many countries, order a name suspended. For most users these are features: they are what makes a domain name predictable. For some users and operators they are constraints, and for a few they are objections of principle.
The motives for building outside the DNS cluster into three types. The first is ideological: a belief that naming infrastructure should not depend on a single coordinating body, however many stakeholders take part in its processes. The second is commercial: for most of the history of the DNS the number of TLDs was small and new ones were hard to obtain, so anyone who could issue a competing TLD could offer names under it without going through an ICANN process. The third is functional: as new uses of names emerged (wallet addressing, decentralized identity, payments), they asked for things the DNS record types and governance model were not designed to provide.
Each generation of alternative naming was driven by one or more of these motives. Each was also limited by the same structural problem: a name is only useful if the software used by the person on the other end can resolve it. Resolution means turning the name into the thing it points to, such as a server address or a wallet address. Keep that constraint in mind through the rest of this account, because it explains more of the history than any technology does.
## Alternative DNS roots in the early commercial internet
The first generation appeared when the commercial internet was young and the choice of TLDs was limited to a handful of generic ones and the country codes. Some groups concluded that if new TLDs were not coming through the official channel, they would publish their own.
### How an alternative DNS root works
The mechanism is simple, and that simplicity is the trap. Every DNS lookup begins with a resolver, the software at your internet provider or on your network that answers the question "where is this name?". A resolver starts from a list of servers that hold the DNS root zone, the master list of TLDs. An alternative DNS root publishes a different master list, usually the official one plus TLDs of its own. A resolver that points to it sees the extra TLDs. A resolver that does not, which is to say almost every resolver in the world, answers that those names do not exist.
Nothing about this requires new technology. It requires persuasion: either each user changes a network setting, or the operators of resolvers agree to follow a different list.
### Two families of operators
Historically, these projects divided into two groups. Some were run for reasons of principle, often by volunteers, and governed by their own communities. They tended to carry the official TLDs alongside their own, so that a user who switched lost nothing. Others were commercial ventures that sold names under TLDs of their own making and looked for distribution: agreements with internet providers, or software installed on the user's computer that redirected lookups.
Both families met the same wall. The community projects found that most people are very reluctant to change a network setting they do not understand, for the sake of names nobody they know is using. The commercial projects found that distribution through providers and bundled software was costly to win and easy to lose, and that it did not produce the trust a naming system needs.
### The collision problem
A second weakness was visible from the start. Because nobody coordinates between alternative DNS roots, two of them can publish the same TLD with different contents. And nothing prevents the same string from later being delegated in the ICANN DNS root. A name then means one thing on one network and another thing elsewhere, or stops working when the official delegation arrives. This is why the engineering community has long treated a single, unique DNS root as a design requirement and not as a preference.
The lesson from this generation is clean. Every commercial case for selling names under an alternative TLD depended on solving the resolver problem at scale, and nobody solved it. The buyers of those names held something that worked for a small circle and for nobody else.
## The first blockchain-based naming systems
The blockchain generation pursued the same goal by a different route. Instead of operating a parallel set of DNS root servers, the idea was to use a public blockchain as the authoritative registry, so that no single operator had to be trusted to keep the list.
### A dedicated chain for names
Namecoin is the example usually cited as the first. It ran a blockchain of its own, modeled on Bitcoin, whose purpose was to record names. A name registered there was held by whoever controlled the corresponding key, and no registrar or registry could suspend it. That answered the ideological motive directly.
It did not answer the resolver problem. That problem changed form. Instead of reconfiguring a resolver, a user now had to run additional software that read the chain, or trust an intermediary that did so on their behalf. For an ordinary user this was more effort than changing a network setting, not less.
It also exposed an incentive problem that the alternative DNS roots had only hinted at. When registration is cheap and open to anyone, and when a name can be held without being used, a large share of registrations will be speculative. The registry fills while the namespace stays quiet. A count of registered names then says very little about use, which is a point this article returns to below.
### Naming as smart contracts
The next wave dropped the dedicated chain. The Ethereum Name Service is the best-known example: it runs as a set of smart contracts (programs deployed on a shared blockchain that execute as written) on Ethereum, and maps human-readable names to addresses and other records. Building on a general-purpose chain meant that the naming system inherited the users, the wallets and the developer tools of that chain instead of having to attract its own.
Other projects of the same period went after the top of the hierarchy instead, proposing to allocate TLDs themselves through a blockchain. The designs differed. The limit they shared with everything that came before was the browser: opening a website at one of these names still needed an extension, a gateway or a specially configured resolver.
## Naming tied to wallets
The change in the practical context for onchain naming was not a technical improvement in name resolution. It was the spread of cryptocurrency wallets as ordinary user software.
A wallet (software that holds the keys to onchain assets) has a naming problem of its own. Addresses are long strings of letters and digits that nobody can remember or type reliably, and a payment sent to a mistyped address is generally not recoverable. A human-readable name that resolves to an address is useful at once to anyone who already has a wallet. That is a different kind of demand from a name that resolves to a website, which has to compete with the whole established system of the DNS and the browser.
The wallet use case gave blockchain naming its first population of users who needed names to resolve, and not only to exist. The [link between onchain names and wallet addressing](/onchain-tld-wallets) is one of the most concrete capabilities in this field: a name issued under a TLD can point to a wallet address, and a wallet that supports the registry resolves it at the moment of payment.
This is a structural shift. The alternative DNS roots needed a change in resolvers across the internet before a name became useful. Wallet-native naming needs only the wallet to support resolution, and wallet developers have a reason to build that support, because it makes their product safer and easier to use. The coordination problem is smaller, even if it is not gone.
It also changes what a name is for. In the DNS, the typical name is a place: a website, a mail server. In a wallet, the typical name is a counterparty: the person or organization you are about to pay. That matters to a brand owner, because a counterparty name is exactly where a customer relies on the name being who it says it is.
## Registries that sell whole TLDs
The commercial model that most directly concerns a brand protection team is not the sale of names under an established TLD. It is the sale of the TLD itself.
Some registries allow a buyer to acquire not a name under someone else's TLD but the TLD, as a token held in a wallet. On Freename, for instance, a TLD is recorded onchain as a token, and only the holder of that token can issue names under it. A Freename TLD held this way is not subject to any annual renewal fee. The registry also operates a royalty program: for every name registered under a TLD, its holder is paid a share of the registration fee, a share advertised at up to half and subject to the registry's current terms and activation conditions.
The nearest thing in ICANN's structure is the dotBrand, a TLD that an organization applies for and runs for its own use. The two are not equivalents. A dotBrand goes through an application process, carries the obligations of running a registry and resolves everywhere the DNS does. An onchain TLD is far lighter to acquire and to hold, and it comes without the coordination that gives a DNS name its universal reach. The [comparison between a dotBrand and an onchain TLD](/dotbrand-vs-onchain-tld) sets the two side by side if you are advising on which route fits a given organization.
For a brand owner, the significance of the TLD-as-token model is twofold. First, registration is generally open, so `.yourbrand` may be held by someone other than you, and that party then decides which names exist under it, `pay.yourbrand` included. Second, if you hold `.yourbrand`, you control the entire namespace under it: nothing is issued there without your authority. Both statements follow from the same rule, that only the holder of a TLD can issue names under it.
## Four generations of alternative naming compared
The generations differ in mechanism and in motive. What limited each of them is closer than the technology suggests.
| Generation | Mechanism | Primary motive | What limited it |
| --- | --- | --- | --- |
| Alternative DNS roots | A parallel list of TLDs served to resolvers | Competition with the official channel; principle | Each user or provider had to change resolver; colliding TLDs |
| Dedicated naming blockchains | A chain built to record names | Names no operator can suspend | Extra software to resolve; speculative registration |
| Naming as smart contracts | Contracts on a general-purpose chain | Wallet addressing; open infrastructure | Browsers still needed extensions or gateways; transaction costs |
| TLD-as-token registries | TLD held as a token; names issued by its holder | Control of a namespace; payments to a name | Partial wallet and browser coverage; no common authority |
Read down the last column and one word recurs under different names: resolution. The rows are best read as successive attempts to shrink the group of people who have to agree before a name works.
## Why earlier attempts stayed marginal
Three structural problems recur across every generation. Understanding them is the basis for assessing what, if anything, is different now.
### Resolution
A name is a pointer. A pointer is only useful if the software that needs to follow it knows where to look. Every alternative namespace has to convince either the dominant resolution infrastructure to add support, or enough users to change their own configuration. Both paths are hard. Internet providers never adopted alternative DNS roots in numbers that mattered. Mainstream browsers do not, as a rule, open blockchain names without added support. Wallet developers have a stronger reason to support names than browser makers had, but coverage is still partial.
### Incentives
The DNS works because registries, registrars and network operators all have a financial interest in maintaining it, and because coordination gives every lookup a single authoritative answer. Alternative namespaces fragmented those interests. An operator who builds a resolver service has no assurance that the naming system behind it will persist. A buyer of a name has no assurance that the resolver they depend on will still answer in a few years. And where names are cheap to register and free to hold unused, registering them on speculation is rational for the individual while the value of the system depends on active use. Each participant behaves sensibly and the namespace stays empty.
### Coordination
Universal resolvability, the property that a name means the same thing to everyone, is something no alternative namespace can confer on itself. It requires a critical mass of resolver operators to agree, and outside ICANN's coordination that agreement has never been reached. The same gap exists between onchain naming systems. No mechanism reserves a string across registries, so the same TLD string can exist in more than one of them, held by different parties.
For a lawyer this third problem is the one to dwell on. In the DNS, the question "who holds this name?" has one answer. Outside it, the first question is "in which system?", and the answer to the second depends on the first.
## What is different now
Skepticism is earned by the history above. But the dismissal that often follows from it ("alternative namespaces always fail, so onchain TLDs will too") misses a structural shift in where names are used.
### Wallets as a place of use
The earlier alternative DNS roots needed an internet provider or a browser to change its behavior before a name became usable for most people. That is a high bar. Onchain naming is being adopted inside the wallet, where names already serve a clear and immediate function: standing in for an address when a payment is made.
A wallet is not a browser. It does not need to resolve names for the whole internet. It needs to resolve them for the people who send and receive onchain payments with it. That population is smaller than the internet, but it has a need that the DNS was not built to serve. Which capabilities work, and in which software, is set out with sources on the page that records [what is live](/whats-live). Resolution is partial and the coverage changes, in both directions.
### Software agents as users of names
A second difference is the arrival of AI agents (software that acts with some autonomy on behalf of a user or an organization) as a new setting where names are used. An agent needs a stable identifier to be addressed by other agents and to receive payments. The DNS can supply one. An onchain name has a property that suits the case: it is a record that software can read and, with the holder's key, manage directly. The work on [identities for AI agents under a TLD](/onchain-tld-ai-agents) is early and its standards are still being drafted, so treat it as a direction and not as an established practice. It is nonetheless a kind of demand that no earlier generation of alternative naming had.
### How a TLD is held
A third difference is the holding model. In the earlier systems, your claim to a name was an entry in a database kept by the operator. If the operator stopped, the entry went with it. An onchain TLD is recorded as a token in the holder's wallet: the registry record is public, and anyone can check it on a block explorer, a public website that displays the contents of a blockchain. This does not make the naming system permanent. The resolvers, the integrations and the registry's own services can still change or stop, and a token that resolves nowhere is of little use. But the record of who holds the TLD no longer depends on one company's private database, and that is new.
## What has not changed
Being precise about what is new requires equal precision about what is not.
### No universal resolution
No onchain naming system resolves everywhere. The latest generation has not escaped the resolver problem: its names resolve outside the ICANN DNS root, and an ordinary browser therefore does not open them without support. For Freename names, that support exists in three places: Bitcoin.com Wallet, MetaMask by way of Freename's resolver, and desktop browsers by way of the Freename Web3 extension. That coverage is real, partial and subject to change. This is not a minor caveat. It is the same structural limit that kept every alternative DNS root marginal. The wallet setting reduces the size of the coordination problem. It does not remove it.
### No common authority
No body arbitrates between onchain naming systems, and none of them is bound by the UDRP, the dispute policy that applies to domain names registered through ICANN-accredited registrars and lets a trademark owner challenge a name registered and used in bad faith. A trademark gives its owner a known procedure in the DNS, through the UDRP and through the courts. The same trademark supports arguments about an onchain name, but the procedural path is less defined and varies by country. Your own counsel decides what weight to give that distinction in a particular situation. This article records the fact of it, not an assessment of the risk.
### No replacement for the web's naming system
As a general-purpose replacement for the names people type into a browser, blockchain naming has not found an audience beyond those already using onchain software. For a public website that must open for every visitor, on every device, without preparation, the DNS is simply better, and nothing in this history suggests otherwise. The onchain systems with the clearest utility are those that serve a wallet-native or agent-native use, not those that set out to substitute for the conventional web.
## What a brand owner should take from this history
The pattern across the generations is consistent: registrations accumulate quickly, resolution lags, and the systems that persist are those that found a specific use, in a wallet or in a defined community, instead of trying to replace the DNS outright. For a brand owner or legal team, three practical conclusions follow.
### Follow the places of use, not the registration counts
A long record of failed alternatives does not make the latest generation irrelevant, and it does not make it important either. What decides the matter is whether a name is used somewhere your customers, partners or suppliers actually are. The wallet payment setting is a departure from the conditions that kept earlier systems marginal, so that is where to look first. If you are briefing colleagues who are new to the subject, the [glossary](/glossary) defines the terms used here.
### Know that the remedy is a different one
In the DNS, a trademark owner can often recover a name through dispute resolution after it has been registered. In onchain registries there is no equivalent of that procedure, so the usual route to a name held by someone else is a negotiated acquisition, not an adjudication. That is a difference of procedure, and it is better understood before a question arises than during one. The page for [brands and legal teams](/brands-and-legal-teams) sets out how that position looks from the side of a trademark owner, and the page on [trademark TLDs](/trademark-tlds) holds the free Trademark Name Check form.
### Look at the TLD level separately from the name level
If `.yourbrand` is held by a third party, that party decides what is issued under it. A single name such as `pay.yourbrand`, resolving in a payment setting, is a more specific matter than an unused TLD in a system nobody resolves. It is worth knowing which of the two you are looking at. A [namespace watch](/namespace-watch) is the ordinary way to keep that picture up to date.
### A concrete next step
Take the three or four strings that matter most to your organization: the house mark, the main product names, the name used for payments. For each one, establish in which naming systems the matching TLD exists, whether names have been issued under it, and in which wallets or browsers those names resolve. Record the result with its source. That one page is enough to tell your counsel whether there is anything to decide, and it replaces a general debate about onchain naming with facts about your own names.
If the exercise shows that a TLD matters to you, or if you hold a TLD and are weighing what to do with it, Hush Partners is a private desk that acts under mandate, for holders who want a buyer and for organizations that want a holder found and approached. The stages of a file are described under [how it works](/how-it-works), and the desk is reached through the contact form on the site.
## Questions people ask
### Does a trademark registration give me enforceable rights against the holder of an onchain TLD?
A trademark registration gives you rights under the law of the country or region where it is registered. Whether those rights can be enforced against the holder of an onchain TLD depends on that law, on how the name is used and on the procedures available there. The UDRP does not reach onchain registries, so the routes are the courts or a negotiation. This is information, not advice: your own counsel decides the appropriate route.
### Why can the same TLD string exist in more than one naming system?
Because each system keeps its own registry and none of them consults the others. Uniqueness in the DNS is the product of coordination through a single DNS root, and no such coordination exists between onchain registries, or between any of them and ICANN. A string can therefore be a TLD in one registry, a TLD held by a different party in a second, and an application or a delegated TLD in the DNS. When you assess a name, establish each of these separately.
### Does holding an onchain TLD give any standing in an ICANN process?
Nothing in the general rules of the DNS gives the holder of a name in another naming system a claim on the same string in the ICANN DNS root. The two are separate systems with separate rules. How a particular application process treats prior use of a string elsewhere is a question for the terms of that process and for counsel.
### Can an onchain TLD be sold or transferred?
Yes. Because a Freename TLD is held as a token in a wallet, it can be transferred to another wallet. In a file handled by Hush Partners, closing runs through onchain escrow on an aftermarket, and every exchange before that is covered by a standard mutual NDA.
### If the registry behind a TLD stopped operating, what would the holder be left with?
The onchain record would remain, since it does not live on the registry's own servers. What would be at risk is everything around it: the resolver, the integrations in wallets and browsers, and the services used to issue and manage names. This is the same dependency that ended earlier alternative namespaces, in a milder form. It is a reason to ask, for any TLD, where it resolves and who maintains that support.