Resolution Overview
Introduction to Web3 Name Services and an overview of Domain Resolution.
Name Services
In previous iterations of the Web, name services allow for information to be associated with different domain names. The Domain Name System, or DNS, is the naming system used for the most popular top-level domains, like .com, .org, .net, and .xyz. One thing made possible by this is more human-friendly addressing of content, such as with HTTP.
A brief overview of the way HTTP's location-based addressing works gives the example text file of example.txt located on a server with an IP of 127.0.0.1 on Port 80.
By using a domain name, our content of example.txt can be reached in a much more human-friendly way. Let's say we have the domain name of example.com, which uses the top-level domain (TLD) of .com. By changing the DNS records of our domain name, we can point our domain of example.com to the server's IP of 127.0.0.1, and with some port forwarding on the server-side, make our content reachable with the domain.
Ethereum Name Service (ENS)
The Ethereum Name Service, or ENS, is a domain name system for .eth domains, a TLD unique to Web3. Similar to the DNS TLDs, ENS domains can be used as a human-friendly name to point to content, but unlike DNS names, ENS is compatible with Web3 resources, such as IPFS content and Ethereum Wallet addresses.
Similar to the example provided for HTTP, a brief overview of the way IPFS's content-based addressing works gives the example text file of example.txt that has been added to IPFS under the Example directory and assigned a Content Identifier (CID).
By using a Web3 resource-compatible domain name, our content of example.txt can be reached in a more human-friendly way. Let's say we have the domain of example.eth, which uses the ENS top-level domain (TLD) of .eth. By changing the content records of our domain name, we can point our domain of example.eth to the IPFS CID of the Example directory, QmUDQd6o7vzanxu319X3RrioWoA9KsADDA7eBT8FWD9JSa, to make all of the directory's content reachable with the domain, in our case the text file contained inside.
Domain Resolution
For Web3 domain names, content records are managed differently from traditional TLDs under DNS. While with a .com domain, the domain name's records are stored on a DNS server, records for Web3 domains utilize smart contracts instead to manage a domain's records. Because management of these records occurs on-chain, a transaction must take place whenever a domain's records are updated. When resolving a domain like a .eth domain, unlike the resolution of a .com domain where records are obtain through a lookup on a DNS server, records are instead obtained from a smart contract interaction that obtains the domain's records from a mapping of domains to content records. This process can sometimes be lengthy, specially with domains utilizing IPNS-type content.
Sagittarius A* provides a resolver that supports ENS domains. This resolver accepts any ENS domain as input, and returns IPFS/IPNS content and Ethereum Wallet address records. For ENS domains specifically, beyond the base resolver functionality is a DNS-like system for recording the records of ENS domains off-chain that can be quickly queried for domain resolution. This works by establishing listeners for the ENS smart contracts that listen for any new transaction indicating that a domain has been registered, renewed, transferred, or updated its content records. Whenever these events are detected, a new resolution of the domain is run to discover the records, which are then recorded in a database containing an off-chain mapping of domain names and content records. This database is regularly updated by new resolution requests, along with regular background resolution to keep records up to date. Via the API, this provides a base means for resolving domains via the ENS smart contracts, with the addition of the database to increase speed and reliability.
Normalization & Subnames
All domains accepted by any endpoint undergo UTS-46 normalization, based on the toUnicode function of the idna-uts46-hx library. Normalization uses the standard ASCII character set and non-transitional processing ({ useStd3ASCII: true, transitional: false }). Additionally, subnames are currently not supported, so while example.eth can be accepted, sub1.example.eth cannot. If a received domain fails normalization, or if a received domain contains a subname, the domain will be rejected.
IPNS
As previously described, updating the records of a Web3 domain requires a transaction to take place for interactions with the smart contracts. For ENS, the smart contracts are on the Ethereum Mainnet, meaning transactions may sometime incur high gas fees. With IPFS, any changes to content result in a new CID. Because IPFS is content-addressed rather than location-addressed, updates to a deployed website for example, would have a new CID that requires a record update if a domain serves the CID directly. However, IPFS provides a system, the InterPlanetary Name System, for creating mutable pointers for IPFS CIDs called IPNS names. These pointers are managed by key pairs, where through signing with the private key, the CID an IPNS name points to can be updated and propagated through the IPFS network, allowing the new content to be available from an unchanging pointer. In the context of domain records, using an IPNS name in content records rather than an IPFS CID provides an option to address changing content without frequently updating the records.
In addition to the resolver provided by Sagittarius A*, support for IPNS resolution is included via the API. Domains resolved to have IPNS-type content undergo automatic IPNS name resolutions to obtain the latest CID the name points to, which is logged in the off-chain mapping of domain names and content records as a cached CID. This allows future resolutions of a domain name to obtain the cached CID from the most recent resolution completed of the domain before the current request as a means to quickly serve IPNS-type content without waiting for a new resolution to complete. A similar system exists for standalone IPNS name resolution on a different endpoint, described on the Resolving an IPNS Name page, which also includes a caching system.
Last updated
