Handshake: Decentralized DNS, certificate authority and naming

Handshake is a brand new blockchain that replaces the ICANN DNS root zone file. It actually starts off with the current root zone, and then extends it. Users can buy TLDs from the Handshake blockchain using an auction process, and register DNS records right on the chain. Handshake ships with a lightweight resolver written in C to make HNS requests available to underpowered machines.

It’s a very cool project, including a massive airdrop of coins to open-source internet citizens. Legacy DNS name owners in the Alexa top 100,000 have their names already waiting for them on chain, claimable with DNSSEC proofs.

We expect mainnet launch within the year.

I wanted to post about in this community because of the Purism dedication to opensource, privacy and decentralization. I think Handshake would be an awesome addition to the Librem line, including the Librem 5 (can’t wait to get mine!).

If anyone’s interested, I’d love to continue this discussion here about including Handshake DNS resolution in Librem products and decentralize the power under the exclusive control of ICANN!

If you wanna go down this rabbit hole, here’s a fat wad of resources:

http://hnscan.com/
https://handshake-org.github.io/



3 Likes

How is it an improvement over namecoin and the .bit domain?

1 Like

I actually like more the GNU’s GNS (GNU Name System) that is libre, decentralized and free.

2 Likes

Namecoin doesn’t have light clients. See this section of the HNS whitepaper: https://namebase.io/handshake-whitepaper/#naming-history for more discussion on prior art.

This is the Handshake light client: https://github.com/handshake-org/hnsd
The new data structure called the “urkel” tree was designed with light clients in mind from the very start.

1 Like

Although other projects can be nice experiments, GNUnet on the Librem 5 is a strategic priority for me. Cannot agree more :+1:

How do GNU Name System distributes domain names to their new owners and how GNU domain name system is censorship resistant?

As I understand these two systems solving two different problems.

Handshake is solving domain names by decentralizing DNS root zone file and replacing ICANN

Where

GNU Network is trying to replace the current Ethernet TCP/IP system

am I wrong?
I do not find any info on how the GNU network would fix the DNS root zone file problem.

There is no hierarchy of authorities to governing the domain names, GNS zones are controlled by a private key. GNS is fully decentralized and stores that information in a DHT. The validity of the records is assured cryptographically, by signing them with the private key of the respective zone. So when we talk about the owner of a GNS zone, that’s really the owner of the private key. Queries and replies
are encrypted, an adversary can only perform a confirmation attack.

1 Like

GNUnet is not trying to replace the current Ethernet TCP/IP system, because it can - but does not have to - run as an overlay network on top of the existing internet. The GNUnet transport system has several plugins for different protocols, like TCP, UDP, WLAN, Bluetooth and one could for example implement a plugin for packet radio.

GNUnet is not only a peer to peer network, but also a framework for applications using that p2p network. The GNU Name System is already an application on top of that framework.

2 Likes

Yes Handshake is an alternative DNS root zone secured by proof of work, it is a new blockchain where everything is streamlined and optimized just for DNS. If I ever get my phone (Evergreen, ordered April 2018) the first thing I’m going to do is try to compile hnsd: https://github.com/handshake-org/hnsd which is a Handshake light client written in C, using unbound as the recursive resolver.

What would be the process to reserve your website name on GNS?

You can not only “reserve” your own website name in GNS. You can do it for all websites, if you like, and you can give what ever name you like to that website.

Let say you create a root zone (Identity) on your own GNUnet peer named “alice”. Now you add a public A record to the zone with ip 195.54.164.39, and you call it “ccc”. You can now resolve your own record with “ccc.alice”.

Now you can give the public key of your root zone to Bob. He adds the public key into his root zone. Now Bob can resolve your record with “ccc.alice.bob”.

You can find examples here: https://gnunet.org/en/use.html

This part is clear to me.
The question is how you will prevent conflicting top-level domains if there is not one root zone? As I understand the biggest problem with TLDs is that to avoid conflicting domains you have to have one centralized root zone. And that’s where ICANN comes, but then it is problem that this centralized entity is the central fail point. And Handshake solves it by holding this one root zone file on multiple machines using a decentralized network, same as the Bitcoin network is holding an account list across multiple machines on a decentralized network.

If conflicting means not getting the same IP address when resolving with the same name depending on whom you ask, this problem boils down to whom you trust.

Remember that you also trust in all the players of the actual hierarchical DNS.

The main points of GNS are:

  • Censorship resistance
  • Query privacy
  • Secure name resolution
  • Compatibility with DNS

But GNS is not just meant to be an alternative for DNS!

Yes and the Handshake resolver has an ICANN “fallback” if a TLD is not in the HNS root zone, the resolver will check the ICANN root zone. I have HNS resolvers set up on all my devices including mobile. There has been no interruption at all with usual browsing and I get the advantage of HNS names. There is a potential conflict if ICANN ever issues more TLDs, that conflict with HNS names. The default behavior in the HNS resolver is to “prefer” the HNS name, but this can be adjusted by the user.

2 Likes