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
Delegate it to
ns1.hns.oneandns2.hns.onewith an on-chain update. After confirmation, ordinary zone-record edits need no further blockchain fee. Signing and DNS caching take time. - 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 that covers that hostname. - You have no name yet
Claim a free label under
claimableon the website. 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
Use the links below to open each service. Some features need a name, a compatible client, or an invitation; each page explains those limits. The full directory, with direct links →
Handshake Appslive
Apps that run on a name and sign you in with a name you already hold — no account, no password. PXLS is the first, and the first app a browser runs live over a name it resolves itself. Handshake Apps →
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, one mailbox password, and public key publication over WKD. Not end-to-end encrypted by default. 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 an ODoH target used through an independent relay. The relay/target feed is served over HTTPS. Experimental. Run your own →
atproto PDSlive
pds.hns.one hosts Bluesky accounts whose handles are Handshake names. Invite-gated. Run your own →
The endpoints
Connection details for supported clients. Check your client settings when choosing a resolver or service.
| 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; no relay on this host |
Config at /.well-known/odohconfigs; /proxy returns 404 |
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.