In Detail: Why’s and How’s of Deploying Our Own DNS
Super Protocol is building a decentralized network with confidential computing at its core (but you should probably know that if you’re a long-term Super follower). In the previous article, we covered how Testnet Phase Two enables this network to host websites with static content. While we’re gearing up for the next leap (which are dynamic applications using NextJS, by the way), there’s another thing that’s not often mentioned, yet imperative for the Super Protocol network to operate and be capable of supporting an unlimited number of applications, services, providers — basically, almost everything that could be found on the internet.
Have you already guessed what it is? And no, we’re not going to talk about high-scale architecture, data centers, or some other facilities typically mentioned in the context of the cloud. You’ve definitely heard the acronym DNS or the Domain Naming System. It’s not a super-hyped thing and usually mentions a spike in the media space when something goes wrong in a big way (like the infamous 2021 Facebook Outage, or the great internet outage earlier that year).
First, a quick refresher on DNS: we already got the “if something is wrong with it, the internet breaks”. In simple terms, DNS makes user-friendly website names possible, so you could enter ‘superprotocol.com’ instead of an abstract combination of numbers. A more complex definition would be DNS is a network service that maps IP addresses to human-readable names. This service is one of the backbones of the modern internet with few trusted providers responsible for most of the web traffic.
So why reinvent the fundamentals once again, while we’ve stated multiple times that it’s way better to reuse already available components? Turns out, having few providers for the networking service as important as DNS is not the best setup if you’re building an unstoppable web of the future. There was no ready-to-use alternative for us, so we went along with building our own.
The good thing about creating your own infrastructural service is having total control over how it’s going to work and the features it could provide. Another awesome thing is removing limitations you’d have with third-party providers, such as a limited number of domains, hosts, or subdomains you could have (for example, with [Cloudflare pages]). Having our own DNS would make the network more flexible and resilient, while also providing more options for its governance in the future.
Security at every level is one of the core ideas behind Super Protocol, so no surprise that with our own DNS, we’d be able to ensure advanced levels of protection, for example, prevent DNS Spoofing (a type of attack when a malicious actor uses a compromised DNS resolver machine to reroute the request to another website, or DNS hijacking which is similar in result, yet uses another type of vulnerability tempering with the resolver’s cache). Of course, traditional things required for a stable secure network, such as SSL certificates, will be added in the future (expected to be already implemented in Testnet Phase 3).
As for the upcoming features, we’re building DNS and components that would come with it and make the Super Protocol network truly decentralized and unstoppable (more on that in our upcoming updates).
