Minimal demo: Register new proper domains like s.country with ONE tokens as registrar extension – such that Tuscow manages the normal flows of fiat purchases and record maintenance. Custody and contact information can be just “Hidden States LLC” for now.
Working with web2 domain systems in web3
The demo website, names.country, was launched a week before Christmas in 2022. It allows users to register a domain under .country that works in web3 and web2 simultaneously, using only payment in ONE through web3 wallets such as MetaMask. This means, when the user purchases a domain (e.g. example.country) through this system, anyone could navigate to the domain in their browser and they will see a functioning website (try opendevelopment.country). Right now, the user who purchased example.country can set a tweet for display on the website. The configuration of example.country is done on the website itself.
.country), the user can also claim a web2 domain. Note that ens.demo.harmony.one is not currently recognized (because it is for .eth). We will deploy an updated ENS frontend soon that works with names.country after we finish reviewing and revising the modifications required on ENS frontend https://github.com/harmony-one/ens-app-v3/pull/1/.Going beyond a simple demo, users would expect to be able to do a lot more using the domain they rented from names.country. For example, to host servers, to receive emails, or to show a website they already set up somewhere else. The most fundamental component in web2 domain systems to support these functionalities is the DNS systems. Users write DNS records which reflect the IP addresses for their server (A record), hostnames for existing websites (CNAME record), mail servers addresses (MX record), and miscellaneous data such as domain ownership verification entries (TXT record). The records are stored in databases, read by the name servers configured for the domain, then propagated to other DNS servers as needed when the domains are used in the applications (such as web browsing).
Here, we want the user of names.country to be able to do the same. A major difference compared to the web2 system is that the user is identified by a web3 wallet address, instead of any username/password account in a particular registrar (such as GoDaddy). Instead of storing DNS records on a centralized database where few could access, we want to decentralize the domain records and store them on the blockchain, so the records and any edits are transparent, fault-tolerant, and traceable.
To do this, we are implementing CoreDNS plugins interoperating with the blockchains, to be used in our DNS servers that are set to be the name servers of domains registered via names.country. When other DNS servers and clients query for the record of a specific domain, our plugins read, parse, and cache corresponding DNS records stored on the blockchain. On the other hand, users who purchased the domain will be able to set their own DNS records on chain. For now, we rely on the DNSResolver implementations in ENS to achieve this purpose, which are already deployed as part of the PublicResolver in our modified ENS contracts and deployment setup (https://github.com/harmony-one/ens-deployer). The DNSResolver contract allows users who leased domains through names.country to set DNS records using DNS wire format (since the users become owner of the web3 domain within the context of our ENS deployment). However, ENS frontend app only allows the user to set a very limited range of record (TXT) in profile page. To allow users writing a rich set of DNS records like they do in web2 registrars, we are creating our own frontend for users to interact with the DNSResolver contracts, which will be deployed on names.country website.
When users lease a domain at names.country, a website is seemingly automatically “generated” under that domain. As explained in the demo, we are planning to allow extensive customization over the content displayed on the auto-generated website. The rationale is that, despite customizable DNS records offer users a way to use the domain just like they do in web2 and to show whatever content they want, this method is too complex for most users because it requires basic knowledge about DNS to operate, which >99% users do not possess.
Behind the scene, no website is generated for each domain. Similar to 1.country, all registered domains are simply directed to the same web server hosting a static website. The code at the client side interprets which subdomain is requested based on the browser’s URL, then loads the corresponding content directly from the blockchain.
However, unlike 1.country, we cannot use the same SSL certificate for all domains, because wildcard matching over gTLD (e.g. a certificate valid for *.country) is not allowed in major browsers (see Chromium source code for example, and disallowed TLDs for wildcard matching). Therefore, we must generate a CA-signed SSL certificate for each domain our system registers (i.e. each domain the user leases).
At this time, we deploy the static website using GCP Load Balancer backed by a GCP Storage Bucket. The frontend of the load balancer serves the SSL certificate via the Certificate Manager, which has a mapping from domains to certificates. The Certificate Manager accepts both custom SSL certificates and GCP managed SSL certificates. Generating either type of certificate requires verifying domain ownership. After evaluating a variety of methods, we decided to generate GCP managed SSL certificates verified by setting a randomly generated DNS record under CNAME. Interestingly, we can make use of our own web3 DNS described above to complete this process: the CNAME record can be set on DNSResolver by the user, or a special operator. To minimize user friction, we will implement this record-setting step on ‣ and assign an operator role to a special smart contract, which can be operated server’s hot wallets. The special smart contract will only allow adding CNAME record matching particular structure to existing DNS record of unverified domain, so to limit the privilege of the server’s hot wallets and reduce security risks. Even if the server is hacked or the hot wallets are stolen, the hacker would not be able to do anything other than creating some meaningless CNAME records on domains pending verification.
There is a limit on the number of certificate we can generate on GCP, and the size of the mapping allowed (under a certificate manager or a load balancer). The default values are only 100 and 1000. Even though we may be able to increase the quota in GCP, eventually we would have to manage and serve our own SSL certificates when we have a large number of users using this product. We have a plan for this using nginx, certbot, and Kubernetes, and of course our web3 DNS and some custom smart contracts. More information will be released in the coming updates.