2 posts tagged with "dns"

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.