SatsDNSPrivacy notice
Last updated: 2026-10-21
SatsDNS is responsible for the personal information described here. For DNS hosting, secondary DNS and dynamic DNS we ask for no name, email address or phone number. An account, if you make one, is a Nostr public key. Registering a domain is the exception: ICANN's rules require the registrant's name, email address, phone number and postal address, which we pass to the registrar and do not keep (see domain registration). This notice lists what the service keeps.
DNS is public by design. The records you publish in a zone, and the addresses you set on a dynamic-DNS hostname, can be read by anyone on the internet. A Nostr public key is public too, and it links every zone, hostname and payment of that account to each other. If you do not want that link, use a separate key, or no account, for each zone.
DNSSEC proofs that a name does not exist also say which names do. Zones and dynamic-DNS hostnames use NSEC3 (RFC 9276: no salt, no extra iterations), so the names cannot simply be listed one after another, but anyone can collect their hashes, and short or common names can be guessed from those hashes offline. Treat every name in a zone, and every dynamic-DNS hostname, as public; choose a long random hostname if it should be hard to find.
What we keep, why, and for how long
| What | Why | How long |
|---|---|---|
| Zones and hostnames: the name, its state, start and end dates, a hash of its token, the owning account's public key (if any), query and change counters, and why it was suspended or removed. After removal the row stays as a record of the name's history. | Running the service, abuse handling, disputes | While the zone exists, then as long as needed for our accounting and tax obligations |
| DNS records of hosted zones and hostnames, and the zone data transferred from your primary for secondary zones, with their DNSSEC keys. While a zone is suspended, a copy of its records is kept so it can be restored. | Serving your DNS | Until the zone is removed (then deleted from both nameservers) |
| Secondary DNS settings: your primary servers' addresses, the TSIG key name, transfer status and recent transfer errors (which may name addresses). Transfer-out peers' addresses. TSIG secrets are kept only by the DNS server, never in our database or logs. | Transferring and serving your zone | Until the zone is removed |
| Accounts: the public key, when it was created, its state and tier, the total paid, the recovery key you set, and your message settings. | Running accounts, limits, recovery | While the account exists; after deletion the key and state stay, linked to the payment and audit records below |
| Dashboard sessions and API keys: hashes only (never the values), the label and scope you give a key, and the day a key was last used (no time, no address). | Signing in and access control | Sessions: deleted 7 days after they end. Keys: until revoked, then kept with the account |
| Signed-request ids (NIP-98 event ids) | Stopping replays | About 2 minutes |
Idempotency records: the stored answer to an order or refund request sent with an
Idempotency-Key | Answering a repeated request the same way | 24 hours |
| Payment records: for paid routes, the Lightning payment hash, or for Cashu a fingerprint of the token's proofs and the mint, with the amounts, the route and the time. For account orders, the invoice (amount, Lightning invoice and payment hash, the bitcoin address we gave you and the transactions paid to it), what was ordered and the result. A double-entry ledger of payments, orders and refunds. No IP address. | Accounting and tax records, checking refund requests | As long as needed for our accounting and tax obligations |
| Refund requests: the invoice, amount, rail and the payout destination you give (a Lightning address, LNURL or bitcoin address), and the outcome. | Paying and recording refunds | As long as needed for our accounting and tax obligations |
| Audit log: each change to a zone, hostname or account (created, renewed, records changed, token rotated, transferred and so on), the time, and who made it: the public key, the API key, or "a token". Not the record contents. | Disputes, recovery, abuse handling | As long as needed for our accounting and tax obligations |
| Message queue: which Nostr direct message is due to which public key, about which zone. The text is built when sending and not stored. | Sending reminders and notices | Deleted 90 days after sending |
| Messages you send us by Nostr direct message: the message, the key it came from and the time. Relays you use also keep a copy under their own rules. | Answering you, refunds, abuse reports | Only as long as needed to answer you, and at most 90 days, then deleted |
IP addresses for rate limiting: the payment gateway's request and connection limits count per
IPv4 address, IPv6 /64 and IPv6 /48, with the plain address as the counter's key, in memory only;
its markers for retries and refunds per address are kept under a keyed hash; a repeated unpaid request is recognised by
a hash of the address together with the request. The API counts new accounts, invoices,
domain checks and abuse reports per IPv4 address or IPv6 /64 and per network (IPv4 /24, IPv6
/48), in memory only, under a keyed hash whose random key is made anew each time the API starts. | Rate limits and abuse prevention | Only as long as the limit they count: the gateway's counters for minutes, repeated requests for up to 15 minutes, retry and refund markers up to an hour, the API's counters a minute to a day; a restart clears all counters held in memory |
Server logs: the edge server logs each request with the path (no query string, no headers) and
your IP address shortened to its first three parts (IPv4 /24, IPv6 /48); the payment gateway logs
your full IP address with the method, path, status and whether a payment proof was sent; the API logs the method, path,
status and time, without your address, and the error text of the DNS server or the domain registrar when one of
them refuses a change (with contact details cut out). Paths contain zone names and hostnames. No log holds tokens, keys, signed
events, L402 credentials, Cashu tokens, invoices or request bodies. | Running the service, fixing faults and handling abuse | 90 days, then deleted (often sooner, because logs are also limited in size) |
Domain registration
The registrant of a domain is on record at the sponsoring registrar, Global Domain Group LLC, not with us. We hold the registrant's contact data only for as long as it takes to hand it to the registrar. The notice and consent that ICANN requires for registrant data are in section 7 of the registration agreement.
| What | Why | How long |
|---|---|---|
| Registrant contact data you give in a registration or transfer order: name, organization, email address, phone number, postal address | Creating the registrant contact at the registrar | Deleted as soon as the registrar has created the contact, or when the order fails or lapses unpaid (at most the invoice's life: 15 minutes for Lightning, 24 hours on-chain). A check every 10 minutes deletes any copy left over. We then keep only the registrar's id for the contact |
Registrant changes sent with PUT /v1/domains/{domain}/registrant | Passing the change to the registrar | Not stored: sent on at once |
| The registrant as shown on a domain's status (name, email address, organization, country) | Showing the owner what the registrar holds | Read from the registrar when asked and held in memory for up to 5 minutes; not stored |
| Daily limit per registrant email address: a keyed hash of the address, with a random key replaced every day | One new registration or transfer a day per address | Deleted after 24 hours; each key is deleted after 2 days, after which the hashes cannot be matched to an address |
| Transfer codes for transfers to us | Starting the transfer | Deleted as soon as the registrar accepts or refuses the transfer; a corrected code is sent on and not stored. Codes for transfers away are not stored at all |
| Domains: the name, its state, dates, the owning account's public key, the registrar's contact id, nameservers, DNSSEC records, lock, verification and abuse state, a hash of its token | Managing the domain, abuse handling, disputes | While the domain is registered through us, then as long as needed for our accounting and tax obligations |
| Domain orders: the domain, years, price, our cost, the state of the order, and the attestation (its text, the agreement version and the time). No registrant data | Accounting and tax records, proof of the order and of the agreement accepted | As long as needed for our accounting and tax obligations |
| Abuse reports by the API form, email or direct message: the domain, category, your text and your contact details | Handling the report | The text and your contact details are deleted when the case is closed. The domain, category, dates and action taken are kept as the record of the case |
Client IP addresses are not stored with any domain, order or report. To check that a registrant email address can receive mail, we look up the mail (MX) records of its domain in the DNS; nothing is sent to the address by us.
What we do not keep
- DNS queries are not logged one by one. We count queries per zone, for the quota.
- Your address when you update a dynamic-DNS hostname with
"auto"is used only to set the record you asked for; the API does not store it anywhere else. - Tokens, API keys, session cookies and TSIG secrets in readable form, Lightning preimages, and the content of requests in logs.
- Tracking of any kind. This website sets no cookies, runs no JavaScript and uses no analytics, fonts or other
third-party resources. The dashboard at
app.satsdns.comsets one session cookie after you sign in, used only to keep you signed in.
Who else is involved
- Lightning: a Lightning payment travels over the Lightning network to the service's own node.
- Cashu: a Cashu token is redeemed at the mint that issued it. Mints are not run by us.
- Bitcoin: on-chain payments are public on the blockchain. We give each order a new address, and we know which order it belongs to.
- Nostr relays: reminders and notices are sent as encrypted direct messages (NIP-17 gift wraps) through public relays, normally the ones your profile lists for messages. To find those we ask public Nostr index relays for your relay list. A NIP-17 message shows relays the recipient, but not the sender or the content. If you turn on the older NIP-04 format as well, relays can also see that the message came from SatsDNS. The dashboard's remote-signer login (NIP-46) uses relays you choose.
- DNS: to check a delegation, we ask your domain's parent zone servers (for example the registry's) for its NS records. For secondary zones, our server connects to the primary addresses you gave.
- Let's Encrypt issues this site's TLS certificates. It receives no information about visitors from us.
- We download public phishing lists to check new names. We do not send your names to any list provider.
- Domain registration: the registrant data goes to the sponsoring registrar, Global Domain Group LLC,
and its affiliate Dynadot Inc (California, United States), which process it under their
privacy policy, and from them to the registry
operator (Verisign for
.comand.net, Public Interest Registry for.org), data escrow agents and ICANN, as described in the registration agreement. Availability searches send the domain name to the registrar. - Bitcoin price: to quote domain prices we fetch the bitcoin price from mempool.space and Coinbase. No information about you is sent.
We do not sell, rent or share personal information, and we do not use it for advertising. We disclose it only where the law requires it, and, for domains registered through us, as described in section 9 of the registration agreement.
Your rights
You can ask what personal information we hold about you, ask how it is used, and ask for it to be corrected. Use the
contact page. Tell us what to look for: a public key, a zone or hostname, or the time of a
payment. We may ask you to prove the link, for example by signing a message with the key or by using the zone's token. We
answer within 30 days. Registrant data is held by the registrar: we can ask it for you, or you can ask its data
protection officer at DataProtectionOfficer@dynadot.com; the owner of a domain can read and correct it
through the API. You can delete an account yourself once it owns nothing. Records that the law requires us to keep,
such as tax records, cannot be deleted before that period ends.
If you are not satisfied with our answer, you may be able to complain to the data protection or privacy authority where you live.
Changes
If what we collect changes, this page changes first, with a new date.
These pages are written in plain language and are not legal advice.