Documentation
What we run, and what trusting us costs.
HNS.ONE is authoritative DNS, a gateway, a mailbox host and a set of identity records for Handshake names. Every page here states the mechanism, the commands, and the limit — including the ones that are not fixed yet.
Start here
Three ways in, depending on what you already have.
- You own a Handshake TLD
Point it at
ns1.hns.oneandns2.hns.onewith one on-chain update — about 0.03 HNS, once — and every record change after that is instant and free. This is the main road. - You want an ordinary-browser address
A Handshake name is invisible to browsers that do not resolve
it.
<name>.hns.oneis the compatibility shim, with a certificate issued for that exact hostname. - You have no name yet
Claim a free label under
14898. No wallet, no tokens, no on-chain transaction by you at all — the label is a record in a zone we sign and serve.
The services
Status words are the honest ones. "Live" means we checked it answering on 2026-08-24; "partial" means some of the promise works and the page says which part does not.
Authoritative DNSlive
ns1.hns.one / ns2.hns.one answer for every name delegated to us. DNSSEC-signed zones, served by nsd.py. Delegate a name →
Gateway mirrorlive
<name>.hns.one serves a name's content-addressed site to any browser, under a certificate issued for that exact hostname. How the mirror works →
Publishingpartial
Upload a folder, we add and pin it to IPFS and write the pointer record. Free on the control-key path. Publish a site →
Maillive
A mailbox at your name, JMAP and IMAP, app passwords, and public key publication over WKD. Not end-to-end encrypted. Mail setup →
DANE / CA-free TLSpartial
A TLSA pin in your signed zone, anchored by a DS record only you can publish. Validated by Wildroot, ignored by every other browser. The DS split →
Identity recordspartial
Nostr, atproto and ActivityPub handles from one name, plus the signed identity receipt. Record reference →
Oblivious DNSexperimental
odoh.hns.one is a live ODoH target and proxy, plus a signed relay/target feed. Experimental. Run your own →
atproto PDSlive
pds.hns.one hosts Bluesky accounts whose handles are Handshake names. Invite-gated. Run your own →
The endpoints
Everything a client talks to. These hostnames are compiled into Wildroot, so they do not move.
| Host | What it is | Notes |
|---|---|---|
ns1.hns.one, ns2.hns.one |
Authoritative DNS, UDP/TCP 53 | Both are 198.44.116.200 — one machine (see below) |
app.hns.one |
The tenant plane: claim, publish, DNS editor, mail setup | Accounts and JSON APIs. No wallet, ever |
<name>.hns.one |
Gateway mirror for a Handshake name | Sends X-HNS-Gateway: passthrough; content addressed on
ipfs/arweave |
query.hns.one |
DoH resolver (RFC 8484), /dns-query |
Resolves Handshake and ICANN names |
odoh.hns.one |
ODoH target /dns-query and proxy /proxy |
Config at /.well-known/odohconfigs |
mail.hns.one |
JMAP /.well-known/jmap, IMAP 993, submission 465 |
TLS only; 143 and 587 are closed |
pds.hns.one |
atproto Personal Data Server | A different machine from everything else |
social.hns.one |
Nostr relay (NIP-11 at the root) | Supports NIPs 1, 9, 11, 42, 45, 70 |
hns.one |
This site, the fediverse instance, WKD, the ODoH feed | Unknown paths answer 200 with this page — do not probe for an endpoint's existence here |
ns1.hns.one and ns2.hns.one resolve to the same address,
198.44.116.200, on the same machine. If that box goes down,
every delegated name stops resolving at once, and you cannot fix it
from your side without an on-chain update that takes up to ~6 hours to
propagate.
This is written down in our own operations notes as the condition to clear before accepting anyone else's delegation, and it has not been cleared. If you are delegating a name you depend on, delegate to a second operator as well — DNS carries multiple NS records natively and nothing about our setup prevents it.
Where the trust actually sits
"Decentralized" describes some of this and not other parts of it. Here is the split, per piece.
- The naming root — no counterpartyHandshake names are issued and renewed by consensus. No registrar, and nothing we run, issues or revokes one.
- Resolution in Wildroot — no counterpartyThe browser verifies names against the chain itself rather than trusting a resolver's answer. Using our DoH or ODoH endpoints is a convenience, not a requirement.
- Published content — no counterpartySites are addressed by their own hash. Whoever serves the bytes cannot alter them without the address changing, and that includes us.
- DNS for a name delegated to us — we are the counterparty Our nameservers answer for your name. We can repoint it. We cannot tamper with content behind a CID. Self-custody stays available and takes one on-chain update.
- Mail, the PDS, the fediverse instance, the relay — we are the counterpartyThese are servers we run and can read. Each page says so in its own words.
Reference
Record conventions
_hns, _atproto, _nostr, DANE TLSA, the identity receipt, and what the DNS editor will and will not let you write. Read →
Self-hosting
The ODoH target, the Handshake-aware Nostr relay and the PDS — what is genuinely runnable and what is local-only. Read →
Wildroot
The browser that resolves these names natively and validates the DANE pins. wildroot.io →
None of this has been through an external security review. We publish
no uptime or user numbers because nothing measures them yet — when
/status measures something real it will say so there.