Last year, I authored a custom implementation for a ENS resolver to provide a true public good to Ethereum given the rampant censorship from the Cloudflare and eth.limo resolvers to certain ENS namespaces and IPFS content.
While eth.limo’s implementation is open source, it is not easily approachable to deploy by the average individual and lacks the desirability for anonymised servicing. Let alone, a concentration to a singular implementation leaves suspectibilities towards broad exploitation across deployments if security is compromised.
The resolver has stood it’s test in production for over 8 months and is used by protocols with large assets under management (AUM) with no critical vulnerabilities disclosed to date. While it remains closed source, it feels unconstructive to leave in it in this state.
The core of the resolver uses Express.js to orchestrate logic to query, retrieve, cache and resolve content and also interconnect resolution to other networks. SSL certificates are generated by using LetsEncrypt’s Greenlock for programmability of dynamic SSL issuance at no extra cost.
Then the constant denial of service attacks (DDOS) the network has been facing the last year require the vanguard extension to be deployed to negate this partially.
To handle DNS wildcard resolution and rate limit connections in negate DDOS attacks Nginx is used.
To truly bring the implementation into production grade release and ensure it’s viability and security, it should go undergo auditing to make it suitable for mass open-source publication. While the implementation is quite lightweight it has some complexities especially when dealing with TOR resolution and security hasn’t been entirely evaluated throughout the stack due to lack of fianncial resources.
Although before auditing, the following needs to be developed:
a) to provide a seamless deployment expierence
b) further support for alternative web resolution
c) further development to reduce latency
d) author an in-depth specification and manual for deployment
Given the widespread attacks on the TOR network, there should be an alternative form of resolution many services have been recently parallelising deployments onto I2P in order to continue to operate admist the TOR network downtime.
In order to make the resolver implementation easily deployable by anyone and to sandbox the individual services for security purposes, all services should be dockerised. With deployment and setup executable through a singular command.
Currently the implementation does not support simultaneous resolution, which is neccessary for scaling for large magnitude deployments. This can be achieved by using Docker in combination with Nginx.
In order for individuals to understand the scope of logic, an in-depth specification should be authored to allow people to acknowledge the architecture. Additionally, simple layman instructions to deploy would be beneficial.
Given that all of these milestones are achieved alongside a security audit of the entire stack, the implementation could be open-sourced for widespread publication and usage.
Given all of the above mentioned milestones, I quote the following expenditures to achieve all of the above with an audit approximating to $10,000 and remaining development costs to $15,000. The approximate timeline for completion being 3 months.
I believe this is a valuable resource for Ethereum, ENS and IPFS, not only for making the portals of access more robust but for diversity in open source implementations. Not forgetting the privacy possibilities of the average individuals leveraging decentralised finance applications while being routed securely.
I will continue hosting the resolver until the end of August but after that I can no longer afford to upkeep it. Thank you for your time and I am eager to hear the community’s input on this proposition.