4 posts tagged with "dns"

In 1995, most organisations did not have a domain name. The ones that did were not always sure what to do with it. Email and a static website were considered ambitious uses. The idea that an organisation might one day operate the bulk of its identity, infrastructure, and customer relationships through structured DNS namespaces would have seemed unlikely to many business leaders.

A small number of companies were thinking differently. They saw the trajectory of the internet, recognised that their organisation was going to need to operate in this new environment, and started building the structures that would let them do it. They registered their domains early. They thought about subdomains for departments, products, and services. They put email addresses on business cards before most of their competitors knew what email was for.

Five years later, those companies looked prescient. Ten years later, they looked obvious.

I think we are at a similar inflection point with onchain identity, and the parallel is worth taking seriously.

Most teams approaching ENS for the first time start with the same question: what do I actually name? It sounds like a small question, but it is usually the hardest part of getting onchain identity right. Get the structure wrong at the start and you can spend years unpicking it. Get it right and everything that comes after is much simpler.

The good news is that we do not need to invent the answer from scratch. Three decades of DNS have already given us a set of patterns that work well, and most of them translate directly to onchain identity.

The most common reason organisations give for not using ENS is not technical. It is not cost either, though that gets mentioned. The real reason, when you talk to enough teams, is that they do not want to manage another identity.

They already have a domain. They already have a brand built around it. Their users know them by it. Their email runs through it. Their website lives on it. Adding a separate .eth name on top of that feels like duplication, and duplication is something experienced operators try to avoid.

There is a related concern that gets voiced less openly, but matters just as much. Their existing domain comes with legal protections they have come to rely on, including trademark coverage, dispute resolution mechanisms, and decades of case law. ENS does not have an equivalent legal layer today. For organisations with valuable brands to protect, building part of their identity on a system without those protections is a real concern.

These concerns are reasonable. They are also both addressed by something most teams do not realise ENS supports.

ENS has supported DNSSEC-enabled DNS names for years. In practice, that means if your organisation already owns a DNS domain such as yourcompany.com, you can import that name directly into ENS and use it as your onchain root. You do not need to register a .eth name. You do not need to manage two identities. You do not need to give up the legal protections attached to the domain you already own.

Most discussions around ENS tend to focus on .eth names as a new primitive — a way for individuals or projects to establish a native onchain identity. That framing is broadly correct, but it misses a second path that is arguably more relevant for organisations: ENS also supports DNS names, and that support changes the nature of the conversation quite significantly.

Instead of asking an organisation to adopt a completely new identity system, ENS allows them to extend the identity they already have. A company can take a domain like example.com, prove ownership, and bring that identity onchain, gaining access to ENS functionality without introducing a new naming surface.

The DNS name base.org lives on ENS, along with base.eth which manages the record

This creates a form of flexibility that is easy to overlook. An organisation can choose to operate entirely with a native ENS name, such as protocol.eth. Or it can bridge its existing DNS identity into ENS and retain continuity with how users already recognise it. Both approaches are valid, and both lead to the same destination: a named, identifiable presence onchain. The difference is how much change is required to get there.