hnsd

You could also try running your own Handshake [1] node or SPV revolver [2] for uncensored DNS results. [1] https://handshake.org [2] https://GitHub.com/handshake-org/hnsd

Handshake has taken a lot of lessons from previous attempts at alternative blockchain DNS roots like NameCoin. Here are some ways its different: - Handshake names are not *.bit domains like NameCoin they're actually top-level domains. This is because Handshake's purpose is not to decentralize domain names per se but too decentralize the root zone and create a more secure root of trust than Certificate Authorities [1] - Handshake name auctions were spread out over the course of the first year after launch to prevent early adopters from hoarding all the good names. For instance, .crypto was available in the first few weeks after launch but .information isn't available until next week. This is important because early adopters hoarding names prevents latecomers from supporting the protocol. - Handshake names are sold via vickrey auction inste

It resolves for me! Try installing a handshake resolver directly like hsd [1] for full chain or hnsd [2] for SPV. [1] https://GitHub.com/handshake-org/hsd [2] https://GitHub.com/handshake-org/hnsd

You can browse Handshake sites with Firefox by using the NextDNS [1] resolver (it's an option in Firefox's Settings). You can also use hnsd [2] or hsd [3] as your resolver. There are a lot of sites and you can see who has claimed their names and/or put up resolvable names on DNS Live [4]. [1] https://nextdns.io/ [2] https://github.com/handshake-org/hnsd [3] https://github.com/handshake-org/hsd [4] https://dns.live/ </shameless>

The JS implemention is a fork of bcoin, the JS Bitcoin full node and production backend. It binds to libunbound but you are right that you would want a lower level language for it to be more scalable. There is a rust implemention work in progress here: https://github.com/UrkelLabs/rsd There is also a C light client here: https://github.com/handshake-org/hnsd For the consensus, there are C bindings for the cryptography and a workerpool that really speeds things up. It could also be possible to dump the Handshake zone into a zone file and serve from behind unbound.

Basically, only the root record parsing is done in JS and then passed to unbound for resolution. Though it is possible to run a pure JS resolver, it's not really recommended. There's also a more portable authoritative & recursive [resolver in C](https://github.com/handshake-org/hnsd). Plus, the whole protocol for node communication and name resolution & proofs is so simple, that it's pretty easy to reimplement in any language.

The way the the ENS integration would work is the DNS request for vitalik.eth would end up at a Handshake Authoritative Name Server and then there are certain blacklisted top level domains (.onion, .tor, .i2p, .bit and a few others) where a client for that protocol is instantiated and then a request is sent out to the appropriate system and then the response would be formatted into a DNS query by the Handshake Name Server and sent back to the client. Not implemented yet, but this is where one would implement it https://github.com/handshake-org/hsd/blob/master/lib/dns/ser... https://github.com/handshake-org/hnsd/blob/master/src/ns.c#L...

- Handshake TLDs need to be renewed every two years or the names go back up for auction. Renewals must include a recent block hash to prove that the name owner is still active and has _recently_ signed the renewal transaction. - Yes, names are rolled out over 52 weeks based on the hash of the name (modulo 52), which was designed to prevent squatting. The auction & renewals processes should help as well. - Yes, Handshake uses proof-of-work. It's a different algorithm (Blake2b keyed with KMAC256) than Bitcoin but still essentially relies on energy consumption for security. - I'm not aware of any other major integrations. But it is easy for users to run their OWN local light client and use it as the DNS resolver for their OS: https://github.com/handshake-org/hnsd