Delegate your TLD once. Change everything after that for free.

Why it can't be done the old way

The chain stores exactly seven record types — NS, DS, GLUE4, GLUE6, SYNTH4, SYNTH6 and TXT. There is no A, no MX, no CNAME. That is not a gap in the design; a root zone's job is to delegate.

It is also why you do not want to keep your records on-chain even where you could. Every change is a transaction with a fee, and it does not reach other people's resolvers until the name tree commits — up to about six hours later. Delegation moves that cost to exactly one transaction, once.

The one on-chain step

You publish a resource on your name containing two NS records and nothing else:

{"records": [
  {"type": "NS", "ns": "ns1.hns.one."},
  {"type": "NS", "ns": "ns2.hns.one."}
]}

Trailing dots as shown. No GLUE4 or GLUE6 — ns1.hns.one is an ordinary ICANN hostname, so it is out of bailiwick and resolvers look its address up the normal way. You never need our IP address to delegate.

If you drive hsd directly

The wallet HTTP API, which is what our own tooling calls:

curl -X POST http://127.0.0.1:12039/wallet/<id>/update \
  -H 'content-type: application/json' \
  -d '{"name":"yourname",
       "data":{"records":[{"type":"NS","ns":"ns1.hns.one."},
                          {"type":"NS","ns":"ns2.hns.one."}]},
       "broadcast":true}'

The equivalent RPC is sendupdate [NAME, RESOURCE]. Either one spends coin and needs your wallet unlocked.

What it costs

Exactly what we can and cannot do once you delegate

• We answer every query at and under your nameThat is what delegation means. yourname, www.yourname, alice.yourname — all of it arrives at our nameservers, and your name resolves if and only if we are up.
• We can repoint your nameWe hold the zone. Nothing in the protocol stops an operator from changing where a name points. That is the trust you are extending, and it is the honest reason to keep a second operator in your NS set.
• We cannot tamper with your published contentA published site is named by its own hash. We can change which hash your name points at — visibly, in a record you can read — but we cannot alter the bytes behind a hash without the hash changing.
• We cannot touch your name on-chainWe never hold your key. Transfers, renewals and the delegation itself all need it, and the panel has no route that could ask for it.
• We cannot change your apex NS or DSThose live on-chain. The DNS editor refuses them for everyone, including us, with the message that they are changed in your wallet.

What you can edit, and where

The editor is at https://app.hns.one/dns/, with a JSON API at /api/dns/records, /api/dns/mutate and /api/dns/pointer. The user-settable types are exactly the set our nameserver can serve and our signer can sign:

A AAAA CNAME TXT MX SRV TLSA CAA NS, and DS only alongside NS.

Limits: 20 records per owner name, 100 per label subtree, owner names ≤ 200 characters, values ≤ 1000 bytes. Addresses must be public unicast — private, CGNAT, loopback and documentation ranges are refused, because "point it at an IP" means one the internet can reach.

Some names are managed by a flow rather than by hand and are shown read-only: _hns.* and _atproto.*, OPENPGPKEY and SMIMEA anywhere (those belong to the mail encryption flow and are an operator-run step, not something the account panel can do today), and _443._tcp* TLSA in zones where DANE is enabled — there, the pin is rewritten on every certificate rollover and a manual edit would be silently overwritten.

You can also delegate a label under your own name to someone else's nameservers. Our server answers with a proper referral, and if you supply a DS alongside the NS we sign it, so the handoff stays secure.

DNSSEC: who signs what

Delegation makes your name resolve. A DS record makes the answers provable. The two halves are deliberately split, because only one of them can be done by someone holding your key.

The record you publish looks like this, alongside your NS records in the same resource:

{"type": "DS", "keyTag": 64223, "algorithm": 13,
 "digestType": 2, "digest": "9ebe72e3f4b8...."}

There is one combined signing key per zone, not a KSK/ZSK pair. It is published with the SEP bit set and signs every RRset directly.

Verify it landed

Ask our nameserver directly, before and after:

# the delegation, straight from the chain
hsd-cli --api-key="$HSD_NODE_API_KEY" rpc getnameresource '"yourname"'

# what we actually answer for it
dig @ns1.hns.one yourname NS
dig @ns1.hns.one yourname SOA
dig @ns1.hns.one +dnssec yourname DNSKEY

A working delegation answers NOERROR with our two NS records and a SOA whose primary is ns1.hns.one. Expect exactly the two NS records and no glue.

Leaving

There is no lock-in mechanism, because there is nothing to lock: we never held your key, and the delegation you published is the only thing pointing the name at us.

Honest status