A name such as alice.eth looks like an Internet domain, but its resolution path is not the same as example.com. A conventional domain normally enters the Domain Name System, where resolvers follow the DNS hierarchy to obtain records such as A, AAAA, MX, or TXT. An ENS name enters a different naming system whose authoritative state is expressed through Ethereum smart contracts.
That distinction is the practical boundary behind many claims about “Web3 domains.” The name can be globally meaningful to software that implements ENS resolution while remaining unknown to a DNS resolver. A browser, wallet, or dApp therefore needs an ENS-aware resolution path before .eth can behave like a useful name.
DNS and ENS answer different lookup protocols
DNS maps names through a hierarchical namespace operated by DNS servers:
application
|
v
DNS resolver
|
v
root -> TLD -> authoritative server
|
v
A / AAAA / MX / TXT / ...For a normal website, the browser ultimately needs an IP address or another DNS result that leads it toward the requested origin.
ENS uses a different protocol model:
application
|
v
ENS-aware library or provider
|
v
ENS Registry
|
v
Resolver contract
|
v
address / contenthash / text / other recordThe ENS documentation describes ENS as a distributed naming system based on Ethereum. Its registry records ownership-related state and the resolver associated with a name. The resolver contract then provides the records for that name.
A DNS recursive resolver does not automatically query those Ethereum contracts. Likewise, reading ENS records does not require walking the DNS root hierarchy for a native .eth name.
The registry does not store every record directly
The ENS Registry is the starting point for resolution, but it is not intended to contain every application record.
Conceptually, the registry answers a question like:
name node -> which resolver handles this name?The resolver then answers record-specific questions:
resolver.addr(node) -> blockchain address
resolver.contenthash(node) -> content identifier
resolver.text(node, key) -> text metadataThis separation is important because the registry controls the delegation boundary while resolver contracts can implement different record behavior.
The common Public Resolver supports several standardized interfaces. ENS also allows other resolver implementations, so applications should resolve according to the resolver interface rather than assuming that all names store data in one fixed contract layout.
ENS names are encoded before contract lookup
An ENS implementation does not use the literal UTF-8 string as a simple database key.
Names first require normalization. ENS currently specifies ENSIP-15 normalization so equivalent user input is canonicalized before hashing. After normalization, the name is transformed through namehash into a 32-byte node identifier used by the contracts.
A simplified view is:
"NaMe.EtH"
|
v
ENS normalization
|
v
"name.eth"
|
v
namehash
|
v
32-byte ENS nodeThis makes input processing part of the security and interoperability boundary. Two applications that disagree about normalization can derive different nodes or present confusing names to users.
For production software, using a maintained ENS library is safer than implementing normalization and namehash handling ad hoc.
An ENS address record is not a web origin
One common ENS use case is mapping a readable name to an Ethereum address:
alice.eth
|
v
0x1234...abcdThat is useful for wallets and dApps, but a blockchain address is not an HTTP endpoint. A browser cannot open a website merely because a name resolves to an Ethereum account.
Web publishing needs another mapping. ENS can store a contenthash record that identifies content in a supported content-addressed system such as IPFS.
Conceptually:
site.eth
|
v
ENS resolver
|
v
contenthash
|
v
content-addressed network or gateway
|
v
site contentThe critical extra step is the client or gateway. Something still has to interpret the contenthash, retrieve the corresponding content, and present it to the user.
Browser support is a resolution-layer problem
Typing site.eth into a browser does not guarantee native resolution.
A conventional browser navigation path is strongly integrated with DNS and HTTP(S). An ENS name requires software that recognizes ENS, queries the appropriate Ethereum infrastructure, interprets the resolver result, and then decides how to obtain the target resource.
That support can be provided by different components:
browser with native/integrated ENS support
|
+--> ENS resolution
browser extension or wallet integration
|
+--> ENS resolution
HTTP gateway
|
+--> gateway resolves ENS
and serves/fetches contentThese approaches have different trust boundaries.
With direct client-side resolution, the application performs or delegates the blockchain lookup through its configured provider. With an HTTP gateway, the user is also trusting the gateway to translate the name and return the expected resource.
That means “accessible in a browser” and “resolved natively by the browser” are not equivalent statements.
A gateway can bridge systems without merging them
A gateway may expose an ENS-controlled resource through an ordinary HTTPS hostname.
For example, the conceptual flow can be:
user
|
v
https://gateway.example/site.eth
|
v
gateway
|
+--> resolve site.eth through ENS
|
+--> fetch contenthash target
|
v
HTTP responseFrom the browser’s perspective, DNS resolved gateway.example. The gateway then performed ENS resolution on behalf of the browser.
This bridge is useful, but it does not convert .eth into a DNS top-level domain. DNS authority remains with the gateway’s conventional hostname, while ENS authority determines the record associated with the ENS name.
The distinction matters for TLS, origin isolation, cookies, caching, phishing defenses, and any policy that depends on the browser’s origin model.
Ownership and registration are separate from resolution
Resolution explains how records are found. Registration explains who controls a name and under what rules.
For .eth, ENS uses registrar contracts. Registration has its own rules and renewal model. A name is therefore not correctly described as permanently owned merely because its state is represented on-chain.
A more accurate separation is:
registrar
|
+--> who may control the name, and under what registration rules?
registry
|
+--> who is the owner/controller and which resolver is configured?
resolver
|
+--> what records does the name return?These are related components, but they solve different problems.
The same distinction also prevents another common mistake: possession of a wallet does not automatically grant control over arbitrary names. Control follows the rules and state of the relevant registrar and registry.
ENS can interact with DNS names without replacing DNS
ENS is not limited conceptually to .eth. ENS includes mechanisms for integrating names that originate in DNS.
That does not erase the existing DNS authority model. Instead, it creates a bridge in which control of a DNS name can be proven and then represented within ENS according to the supported integration mechanism.
This produces two separate questions:
Who controls example.com in DNS?
Who controls the corresponding representation inside ENS?A correct integration has to preserve the authority relationship rather than simply letting an unrelated wallet claim an existing DNS name.
This is another reason “Web3 domain” is an imprecise umbrella term. A native ENS .eth name and a DNS name imported into ENS can share resolution tooling while having different registration and authority paths.
Wallet resolution and website resolution should not be conflated
A wallet usually wants a machine-readable blockchain destination:
recipient name -> blockchain addressA web client may instead want:
site name -> contenthash -> contentAnother application may query text metadata, avatar records, service endpoints, or other resolver interfaces.
The same human-readable name can therefore expose several records without implying that all software will interpret them identically.
Application code should ask for the record it actually needs. Treating every ENS name as if it were an HTTP hostname collapses distinct protocol layers into one abstraction and creates incorrect assumptions about connectivity and trust.
The useful boundary is authority plus resolver support
A Web3 naming system is valuable when applications agree on two things: who has authority to update a name, and how its records are resolved.
ENS places those functions in explicit protocol components:
registration authority
|
v
registry state
|
v
resolver selection
|
v
typed record lookup
|
v
application interpretationDNS solves a similar human-factors problem—turning names into machine-usable information—but through a different authority and resolution architecture.
For that reason, ENS should not be treated as a drop-in replacement for DNS. It is a separate naming system that applications can integrate directly or bridge into conventional web infrastructure. The practical behavior of a “Web3 domain” therefore depends less on the visual form of the name than on the resolver path, client support, and trust boundary used to turn that name into an address or resource.