Background
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.
Implementation overview
Express.js
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.
IPFS
A running of the Kubo daemon is required to pin, pull and cache content from IPFS, all handled programmatically with the ipfs-http-client package. IPNS resolution support also is present.
TOR
A running instance of the TOR daemon is required to serve onion services and route connections through circuits. Communication between Express is programmatically achieved through using an old small getter library tor.js for interacting with the daemon via javascript, it required some small improvements to become functional. Reverse onion resolution is also supported as clearnet resolution to reveal the onion link can be deemed as deanonymising if accessed unshielded.
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.
Nginx
To handle DNS wildcard resolution and rate limit connections in negate DDOS attacks Nginx is used.
Proposition
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
I2P support
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.
Dockerisation
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.
Loadbalancing
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.
Documentation
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.
Expenditures
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.
Conclusion
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.