As protocols strive for increased decentralization, operating community-owned frontends remains a fleeting goal for most projects. One particular challenge lies in the domain registration process where the responsibility of maintaining a domain falls upon an individual or entity. Such centralized control introduces a single point of failure as the domain owner can alter domain records at will.
Additionally, IPFS-hosted webpages linked through DNSLink depend on gateways that might not themselves be secure and trustless. Such workflows might introduce possible security risks. In this piece, we look into how 3DNS’s on-chain DNS management solution coupled with Oyster’s secure enclave guarantees can streamline frontend deployment for DAOs.
Enter 3DNS domains
The introduction of 3DNS enables on-chain-managed domains that address some of the challenges in decentralization. It gives smart contracts the ability to manage domains, in turn allowing a decentralized autonomous organization (DAO) on the blockchain to control them.
Managing DNS records on-chain has one major advantage, namely, access control. Only authorized keys can update DNS records which prevents insider jobs, database leaks or email hacks at the DNS provider from causing unauthorized updates to DNS entries. Moreover, it gives the community a vote on deciding the particular deployment and codebase their domain should point to.
However, this does not completely resolve the issue of hosting applications in a trustless manner.
1. The domain still needs to point to an IP address where the hosting provider can update the code running on the server at will (possibly a phishing site).
2. The DAO needs to vote and update records every time the IP address of the instance hosting the frontend changes.
A way to deploy sites is thus required where smart contracts can automatically verify the codebase running in the server and point DNS records to that host only after it checks that the code running in it matches a pre-authorized template.
Oyster can enforce ‘code is law’ off-chain
The Oyster platform is based on secure enclaves, also known as Trusted Execution Environments (TEEs). TEEs are isolated from the host machine at a hardware level and have two critical properties that make them perfect for the challenge described above:
1. Integrity: Code running inside a TEE can’t be modified by the host machine. Furthermore, code running inside a TEE can be verified to be the same as that was intended to be deployed using attestations (think of it as a signed hash over the code).
2. Confidentiality: Code or data inside the TEE can’t be accessed by the host machine. Thus, SSL certificates can be issued to enclaves running on untrusted hosts without the risk of the host misusing it to serve phishing sites.
Oyster can therefore be used in conjunction with 3DNS domains to design a secure on-chain frontend hosting service using Certification Authority Authorization (CAA) records. A CAA record is a type of DNS record that specifies which certificate authorities (CAs) are authorized to issue digital certificates for a domain. It can also be used to restrict who can request certificates for that domain (which are enclaves running pre-authorized templates as per the design discussed here).
Binding domains to a secure enclave (on Oyster) using CAA records (on 3DNS)
Before we get started with the implementation details, one last concept to understand the workflow is Automatic Certificate Management Environment (ACME). ACME is a protocol that allows an account (the "ACME account") in a host machine (the "authorized server") to get an SSL certificate for a certain domain from a certain CA. Think of an ACME account as a keypair that has been authorized by the CA to sign certificates for the domain.
With the prerequisites covered, we can now proceed with the steps to allow SSL certificates to be automatically issued to the correct host machines.
Step 1: DAOs maintain and share a community-vetted frontend codebase. The frontend codebase along with the auxiliary code required to set up TLS (using ACME) and serve HTTPS requests is packaged into an enclave image (the “authorized image”). The image generates the ACME account inside the enclave, thus keeping the corresponding private key invisible to the external world. Since such an enclave image can be standardized, its image hash (the “authorized image hash”) can be shared publicly.
Step 2: The ownership of the 3DNS domain is transferred to a contract (the “DNS admin contract”) where a DAO can possibly be the contract admin.
Step 3: Every time the authorized image is updated, the DAO updates the DNS admin contract with the authorized image hash.
Step 4: Since the ACME account is initialized inside the enclave, the authorized image needs to have functions that expose an endpoint to query the ACME account URL (similar to an RSA address or public key) and CA (corresponding to whom the ACME account was created). These details along with information of the binary running in the server is signed (the “attestation”) using the enclave’s private key ensuring no one outside the enclave can spoof it. Hence, any untrusted community member can run an authorized server.
Step 5: Any authorized server can provide the attestation to the DNS admin contract to update the CAA record. If the binary information in the attestation matches the authorized image hash, the CA that is responsible for issuing certificates as well as the ACME account that can request certificates is updated to allow the authorized server to start establishing SSL connections for the domain.
Eureka! We can now have CAA records managed by a DNS admin contract enforce that only enclaves running authorized images request certificates for a domain. This ensures that any response received by users visiting the domain can be authenticated as originating from the intended application as the certificate wouldn’t be issued otherwise, ensuring that it hasn’t been tampered with.
By combining Oyster and 3DNS, one can finally build truly decentralized frontends, changing the way we interact with Web 3 altogether. Look forward to a hands-on tutorial in the coming weeks.
About Marlin:
Marlin is a verifiable computing protocol featuring TEE and ZK-based coprocessors to delegate complex workloads over a decentralized node network. Servers provisioned using smart contract calls host ML models, frontends, MEV or automation bots, or backends for arbitrary computations using external APIs with baked-in auto-scaling and fault tolerance. Marlin is backed by Binance Labs and Electric Capital.
Follow our official social media channels to get the latest updates as and when they come out!
Twitter | Telegram Announcements | Telegram Chat | Discord | Website
Subscribe to our newsletter.
