Need help with hnsd?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

212 Stars 35 Forks Other 443 Commits 27 Opened issues


Handshake SPV name resolver

Services available


Need anything else?

Contributors list


SPV resolver daemon for the Handshake network. Written in C for speed/size/embedability.


hnsd exists as a 4-layer architecture:

  1. An SPV node which syncs headers and requests name proofs and data from peers over the HNS P2P network.
  2. An authoritative root server which translates the HNS name data to DNS responses. These responses appear as if they came from a root zone.
  3. A recursive name server pointed at the authoritative server, which serves
    as a stub zone
  4. A hardcoded fallback for ICANN's root zone, residing in the authoritative layer.

A standard stub resolver can hit the recursive server with a request. The flow looks something like this.

stub resolver
  -> +rd request
  -> recursive server
  -> libunbound
  -> +nord request
  -> authoritative server
  -> spv node
  -> proof request
  -> peer

Coming back, a response will look like:

  -> proof response
  -> spv node
  -> authoritative server
  -> translated dns response
  -> libunbound
  -> recursive server
  -> dns response
  -> stub resolver

This daemon currently stores no data, and uses about 12mb of memory when operating with a full DNS cache.

This architecture works well, given that there's two layers of caching between the final resolution and the p2p layer (which entails the production of slightly expensive-to-compute proofs).

The recursive resolver leverages libunbound's built-in cache: there is, however, also a cache for the authoritative server. This is atypical when compared to a standard RFC 1035 nameserver which simply holds a zonefile in memory and serves it. All current ICANN-based root zone servers are RFC 1035 nameservers. We differ in that our root zonefile is a blockchain. With caching for the root server, new proofs only need to be requested every 6 hours (the duration of name tree update interval at the consensus layer). This substantially reduces load for full nodes who are willing to serve proofs as a public service.



  • libuv >= 1.19.2 (included)


hnsd will recursively build and statically link to

, which is included in the source repo.

Installing Dependencies


$ brew install git automake autoconf libtool unbound


You're a Linux user so you probably already know what to do. Make sure you have git, autotools, libtool, and unbound installed via whatever package manager your OS uses.


Windows builds are made natively with MSYS2 / MinGW. This uses the MinGW libunbound and OpenSSL packages provided by MSYS2.

  1. Install MSYS2 from - follow the instructions on that page
  2. Install dependencies - do one of the following in an MSYS2 shell
    • x8664: `pacman -S base-devel mingw-w64-x8664-toolchain mingw-w64-x8664-unbound mingw-w64-x8664-crt-git`
    • x86:
      pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-i686-unbound mingw-w64-i686-crt-git
  3. (Optional) You can install git if you want to use it from the MSYS2 shell -
    pacman -S git
    • Git for Windows works fine too but avoid mixing the two, they may not handle line endings the same way
  4. Then build normally from the MSYS2 shell.

The Windows build will dynamically link to the MinGW libunbound and OpenSSL DLLs. You can run it from the MSYS2 shell, which sets PATH appropriately, copy those DLLs to the hnsd directory, etc.


$ git clone git://
$ cd hnsd


$ ./ && ./configure && make


$ sudo make install


Currently, hnsd will setup a recursive name server listening locally. If you want to resolve names through the handshake network, this requires you to change your resolv.conf to, as well as configure the daemon to listen on port 53 -- this requires root access on OSX, and some hackery on Linux.


  1. Open "System Preferences" on the panel/dock.
  2. Select "Network".
  3. Select "Advanced".
  4. Select "DNS".
  5. Here, you can add and remove nameservers. Remove all nameservers and add a single server: "". You can change this back to google's servers ( and later if you want.
  6. Run hnsd with
    $ sudo ./hnsd -p 4 -r


First we need to alter our resolv.conf:

echo 'nameserver' | sudo tee /etc/resolv.conf > /dev/null

Secondly, we need to allow our daemon to listen on low ports, without root access (much safer than running as root directly).

$ sudo setcap 'cap_net_bind_service=+ep' /path/to/hnsd

Now run with:

$ ./hnsd -p 4 -r

Using a static resolv.conf

On Linux, there are a few services which may try to automatically overwrite your

. resolvconf, dhcpcd, and NetworkManager are usually the culprits here.


If you're using resolvconf,

must be modified:
$ sudo vi /etc/resolvconf.conf


field must be altered in order to truly alter your resolv.conf:


dhcpcd may try to overwrite your resolv.conf with whatever nameservers are advertised by your router (usually your ISP's nameservers). To prevent this,

must be modified:
$ sudo vi /etc/dhcpcd.conf

In the default config, you may see a line which looks like:

option domain_name_servers, domain_name, domain_search, host_name

We want to remove

, and
option host_name


Likewise, NetworkManager has similar behavior to dhcpcd. To prevent it from tainting your resolv.conf,

must be altered:
$ sudo vi /etc/NetworkManager/NetworkManager.conf

The default

is usually empty, but we need to add a
option under the
section, resulting in a configuration like:

Note that NetworkManager will also check connectivity by resolving a domain. This can cause issues with hnsd. Disable with:



Windows users: your system may alter the "end of line" characters in certain files that will break the build inside docker. To prevent this, add this option to your git global configuraiton before cloning this repo:

 $ git config --global core.autocrlf input

Building an image

To build a Docker image with the name

, run:
$ docker build -t hnsd .

Running a container

To create and run a container named

, run:
$ docker create \
  --name=hnsd \
  --publish= \
  --restart=unless-stopped \
  hnsd -r
$ docker start hnsd

To check the

container if it runs correctly
$ docker ps -a

Stopping a container

To stop a container named

, run:
$ docker stop hnsd


To build hnsd as an OpenWRT package you'll need to rename

and put it in
before building. Then you can use your
and select it.
Or you can use this command if you want to build on your SDK this package only:
$ make package/net/hnsd/compile V=s

Please keep in mind that

and all of its dependencies such as
libsodium, libmnl, libevent2(all packs), libpthread, libnghttp2, python3-base,libprotobuf-c
and some of them are reqired to be installed manually.


$ hnsd [options]


-c, --config 
  Path to config file.

-n, --ns-host IP address and port for root nameserver, e.g.

-r, --rs-host IP address and port for recursive nameserver, e.g.

-i, --ns-ip Public IP for NS records in the root zone.

-u, --rs-config Path to unbound config file.

-p, --pool-size Size of peer pool.

-k, --identity-key Identity key for signing DNS responses as well as P2P messages.

-s, --seeds Extra seeds to connect to on P2P network. Example: -s [email protected]

-l, --log-file Redirect output to a log file.

-d, --daemon Fork and background the process.

-h, --help Help message.



command will output two binaries into the root directory:
, which is compiled from unit tests in the
directory. Run the tests with


  • Copyright (c) 2018, Christopher Jeffrey (MIT License).

See LICENSE for more info.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.