Handshake

So You Want to Run a Handshake Node

Handshake is a decentralized top-level domain system. It operates as an alternative root zone on its own blockchain. When you buy a TLD like .bit or .hns, you own it outright. No ICANN, no renewal fees, no registry pulling the plug. I ran a full node for about three years before moving to a lighter setup because the sync time on mainnet was eating my weekends. The protocol uses a proof-of-work chain. Auctions happen for every new TLD. The highest bidder wins the right to operate that zone. It sounds straightforward until you're dealing with the actual software and trying to understand the difference between a full node, a light client, and what most people call "running Handshake" when they really just mean hosting a resolver.

What Handshake Actually Is Before You Touch Anything

Most people confuse Handshake with regular DNS. It isn't. Handshake is a naming layer built on a blockchain. The name .bitcoin resolves through the HNS network, not through ICANN's root servers. When you query a Handshake domain, your resolver needs to know how to reach that alternate root. That's the entire complexity. The software is open source and available at handshake.org. The daemon is called hsd. You compile it from source or grab a binary release. The GitHub repo is primarily maintained by Adam Lupek and the broader community. There's no company behind it, which means support is essentially whatever you can find on the forums and Discord.

Installing and Running the Daemon

I started with a fresh Ubuntu 22.04 VPS, 4 cores, 8GB RAM, and a 1TB NVMe drive. You need at least that much disk space because the full blockchain grows continuously. The initial sync took me about 36 hours on that machine. After that, transactions add maybe 50MB per month depending on auction activity. Compile it directly from source rather than using package managers unless you want an outdated version. Run make and then make install. The config file lives at ~/.hsd/hsd.cfg. You'll want to set at minimum: datadir, rpcuser, rpcpassword, and port. Keep the default port at 36115 unless you have a reason to change it. The RPC interface runs on 36125 by default. Once the node is running, verify it with hscli getinfo. If the block count matches the current height on the blockchain explorer, you're connected. The first time I checked, my node was only at 40% of the real height and I wasted two hours troubleshooting before realizing the firewall was blocking incoming p2p connections on port 36115. Check your inbound rules before anything else.

Configuring Resolvers and Zone Authority

Here's where things get messy. If you own a TLD like .test, you become the de facto authority for that zone. That means you run a nameserver that answers queries for everything under that TLD. The hsd software includes a nameserver component called hsd-nameserver. Configure it in the same config file with the bind address and the zone you're authoritative for. I learned the hard way that being authoritative for a zone doesn't mean the internet will find you. Your nameserver needs public DNS A records if you're delegating properly, but since there's no central registry, nobody registers those delegation records for you. Most people just point resolvers directly at their IP and skip delegation entirely. It works fine for personal use. It breaks completely if someone queries through a standard recursive resolver that doesn't know about your TLD. For individual domain registration, you send a transaction to the network. The command looks like hsd-cli sendtx with the appropriate operation type. Registration fees are paid in HNS tokens. Current registration runs anywhere from a fraction of a cent to a few dollars depending on how much competition there is for that name. Popular names go to auction. Obscure names are practically free.

The Stuff Nobody Warns You About

The blockchain gets congested during auction periods. I watched gas fees spike to around 0.005 HNS per transaction during a particularly active landrush for .finance. That's not dramatic money, but it matters when you're trying to register multiple names and the mempool backs up. My transactions stalled for six to eight hours one time. The workaround was switching to a different relay node and rebroadcasting after an hour. Another issue that bites people regularly: the nameserver component doesn't cache aggressively by default. If you're running a resolver for a small network of machines, every query hits the blockchain for every TLD you don't control. Set the cache size explicitly in your config. I bumped mine to 10000 entries and saw query latency drop from averaging 200ms to around 30ms for repeated lookups. The tradeoff is memory usage climbing to about 200MB for the resolver process. The biggest practical limitation is adoption. A Handshake domain works if your resolver knows about Handshake. Most browsers don't. Most operating systems don't. You need to configure your DNS resolver to support HNS queries, typically by pointing it at your own handshaked node or a third-party public resolver like those offered by handshake resolver services. Without that configuration step, .bit and .hns addresses simply don't resolve. They return NXDOMAIN because the standard recursive path has no idea what to do with them.

If you're evaluating whether this is worth your time for production infrastructure, the honest answer is it depends entirely on what you're protecting against. The security model is solid. The ecosystem is narrow. Most of what Handshake does better than traditional DNS, you probably don't need unless you're specifically worried about single points of failure in the naming hierarchy or you want truly uncensorable domains. For a home lab project, a personal blog, or internal tooling, it's a fine exercise. For anything that needs broad compatibility, it's a liability you're buying into.