Your domain.
No registrar needed.
Register a .nodns.shop subdomain instantly. Pay with Cashu sats. Records propagate via Nostr in seconds.
What is NoDNS?
NoDNS is a protocol that resolves DNS records from Nostr events. Instead of registering domains through a traditional registrar and configuring DNS through a control panel, users publish cryptographically-signed events to Nostr relays. A NoDNS-compatible nameserver reads these events and serves them as standard DNS responses.
No accounts. No passwords. No billing. Your Nostr keypair IS your domain credential. Anyone with a Nostr key can claim a subdomain under nodns.shop and point it anywhere they want.
Custom names like alice.nodns.shop are possible through cryptographic delegation. A zone registrar signs a Nostr event granting a pubkey exclusive control over a human-readable name for a time period. This delegation is irrevocable— even if the registrar removes the DNS records, the Nostr event remains the authority.
Decentralized
No central authority controls your records. Your private key is your proof of ownership. No one can take your domain or modify your records without it.
Instant
Publish an event and your DNS records propagate globally in 3-5 seconds. The bot subscribes to relays in real-time and pushes changes via DDNS immediately.
Standard DNS
Queries resolve via normal DNS protocol. Any resolver, any operating system, any device. No special software needed to look up records.
How It Works
Generate Keys
Create a Nostr keypair. Your public key (npub) becomes your domain identifier under nodns.shop.
Publish Event
Construct a kind 11111 Nostr event with your DNS records as tags. Sign it with your private key and publish to relays.
Bot Processes
The nodns-bot subscribes to relays, validates your event, checks policy rules, and pushes records to the authoritative DNS server via DDNS.
DNS Resolves
Within seconds, your records are live. Standard DNS queries return your published records. Zero special software needed on the resolver side.
Consensus Rules
Who decides what a name resolves to?
There are two hard problems in programming: cache invalidation, naming things, and off-by-one errors. NoDNS doesn't try to solve naming for the whole world. It provides a framework where different consensus rules can coexist. The question 'who owns this domain?' has different answers depending on which consensus rule you follow. Nothing described here is production. Everything is a thought experiment.
⛔ No Token. Ever.
NoDNS will never create a token. Naming is a utility, not an investment.
Anti-spam
Sats burned to miners (proof of work equivalent, no beneficiary)
Namespace lease
Sats paid to the parent domain operator for subletting their namespace
No token sale, no governance token, no staking, no ICO. If someone creates a $NODNS token, it's a scam.
Consensus Models
Traditional DNS
Registrar decidesThe existing DNS system. You register a domain through a registrar, who leases it from a registry, who operates under ICANN's authority. A court order can seize your domain. A registrar can refuse to renew. Someone above you always has power over your name. This is what everyone uses today and it works fine for most things.
Authority: Institutional hierarchy (ICANN → Registry → Registrar → You)
Resolution: DNS query → recursive resolver → authoritative nameserver → records
Crypto Naming Tokens
Token decidesVarious projects have created naming systems backed by blockchain tokens. You buy a name, you get a token that represents ownership. The smart contract or chain consensus enforces who controls the name. NoDNS takes a different path: no token, no blockchain.
Authority: Smart contract / blockchain
ENS — Ethereum-based, .eth names, auction + annual renewal
Unstoppable Domains — Polygon-based, one-time purchase, .crypto/.x/.nft
Handshake — Own blockchain, auction-based TLDs, PoW
Resolution: Special resolver / browser extension → blockchain RPC → contract state → records
$npub.nostr
Private key decidesThe purest consensus rule: your public key is your domain under .nostr. Nobody can take it from you because nobody can forge your signature. Nobody can squat someone else's public key because they can't produce valid events for it. Defined in an experimental draft. Requires installing a local resolver — not resolvable by standard DNS.
Authority: Cryptographic (nsec/npub — your keypair IS your domain credential)
Pattern: {npub}.nostr → npub1axfc8yyaycvnqawkusq7p9pcfgzaw74jgme6c9ez5vcde3pq3d2sgufgdg.nostr
Ref: nodns-nameserver by Arjen
Resolution: Local DNS server (nodns-ns) → subscribes to Nostr relays → serves from cache
$npub.{parent_domain}
Private key decides, parent domain cachesThe same rule as $npub.nostr, but under an existing parent domain. Your npub IS your subdomain. The parent domain operator runs a bot that subscribes to Nostr relays and pushes records to standard DNS via DDNS. This means anyone can resolve it with normal DNS — no special software needed. The operator can be paid to cache/mirror your records, but the Nostr events are the source of truth. This is a land grab: the parent domain operator is placing a new consensus rule above their own authority.
Authority: Cryptographic (nsec/npub) + parent domain operator mirrors to standard DNS
Pattern: {npub}.{zone} → npub1ykal2...pa3dl.nodns.shop
Ref: Protocol experimental draft
DNS
Standard DNS query → zone's nameserver → recordsNostr
Nostr relay subscription → event verification → recordsConflict
Nostr always wins. If DNS returns different records than Nostr events, someone is tampering with DNS (MITM) or a court has ordered changes. The Nostr events remain the cryptographic truth.$string.{parent_domain}
Parent domain delegates authority to a private keyAn existing domain owner delegates a human-readable name to a specific npub for a fixed duration. The delegation is a signed Nostr event — irrevocable within the validity period. The operator is subletting their namespace. They choose to recognize Nostr events as the authority for their zone. Payment goes to the parent domain operator as a lease of their namespace. Censorship-resistant at the Nostr layer (delegation event can't be forged), but a court can order the operator to change DNS records.
Authority: Delegation from parent domain owner (via signed Nostr event)
Pattern: {name}.{zone} → alice.nodns.shop
Ref: Protocol experimental draft
DNS
Standard DNS query → zone's nameserver → recordsNostr
Nostr relay → delegation event + record events → verify signatures → recordsConflict
Nostr events are the truth. DNS is a cache. If they disagree, DNS has been tampered with.$string.pob
Burn sats to claim a namespaceA speculative consensus rule where you prove you burned Bitcoin (sending sats to unspendable addresses, contributing to Bitcoin's security) to claim a namespace. Based on ThomasV's proof-of-burn model for Nostr namespaces. The idea: burning is costly, so names have implicit economic weight. No token is created — sats go to miners.
Authority: Economic commitment (sats burned to miners)
Pattern: {name}.pob
$string.wot
Your social circle decides what the name resolves toA highly experimental model where a name resolves differently depending on which social circle you belong to. Much like how 'the pub' means different places to different people depending on their context, a WoT domain resolves based on who you trust. Your web of trust defines your namespace. Not yet explored in depth.
Authority: Social graph (who you trust determines resolution)
Pattern: {name}.wot
$string.eburn
Exponentially increasing cost to take over a nameA variant of Proof of Burn where the cost to take over an existing name increases exponentially. If you burned 1000 sats to claim 'alice.eburn', someone else would need to burn 10,000 to take it. Then you'd need 100,000 to reclaim it. The exponential curve makes it prohibitively expensive to dislodge a legitimate owner. Not yet explored in depth.
Authority: Economic commitment with exponential defense
Pattern: {name}.eburn
At a Glance
| Model | Who Decides | Token? | Censorship Resistance | Standard DNS? | Status |
|---|---|---|---|---|---|
| Traditional DNS | Registrar/ICANN | No | None | Yes | External |
| Crypto Naming (ENS etc.) | Smart Contract | Yes | High | No | External |
| $npub.nostr | Private Key | No | Absolute | No (local resolver) | Draft |
| $npub.{parent} | Private Key | No | Absolute | Yes | Proof of Concept |
| $string.{parent} | Delegated Key | No | Partial | Yes | Proof of Concept |
| $string.pob | Highest Burner | No | High | TBD | Thought Experiment |
| $string.wot | Social Graph | No | Inherent | Probably not | Research TODO |
| $string.eburn | Economic Defense | No | High | TBD | Research TODO |
What all of these have in common
Every model above is just a different consensus rule — a different social contract about what 'looking up a name' means. Traditional DNS says 'the registrar decides.' ENS says 'the smart contract decides.' NoDNS says 'the private key decides, and the parent domain operator can be paid to cache.' Proof of Burn says 'economic commitment decides.' Web of Trust says 'your community decides.' They're all trying to answer the same question: when someone types a name into their browser, who gets to say what it resolves to?
No token: NoDNS will never create a token. Any payment is either burned as anti-spam or paid to the parent domain operator as a lease of their namespace.
Research: Researching other name resolution methods beyond what's listed here is an open TODO. If you have ideas, open an issue.
Nothing described here is production. The protocol is an experimental draft. The proof-of-concept is live at nodns.shop. Everything else is a thought experiment.
DNS Record Browser Live via Nostr
The same records, verified from three independent sources. The signed Nostr event is the authority.
Live Event Feed
Nostr DNS Dashboard
Generate keys, publish DNS records as Nostr events, and manage your nodns.shop domain.
Identity & Domain
Publish DNS Records
Generate or load a keypair first to publish records.
Try It Now
Test resolution against the nodns.shop nameserver:
# Query an A record (resolves to 185.18.221.10)
dig npub190queyng2pmx0jfw5rkx4fjjl3u0zxz6nlyaja53p2n0ydupr6jsdnqt8q.nodns.shop A
# Query a TXT record (resolves to "cool stuff!")
dig npub190queyng2pmx0jfw5rkx4fjjl3u0zxz6nlyaja53p2n0ydupr6jsdnqt8q.nodns.shop TXT
# Query a subdomain with CNAME
dig www.npub1hw6amg8p24ne08c9gdq8hhpqx0t0pwanpae9z25crn7m9uy7yarse465gr.nodns.shop
# Full trace
dig +trace npub190queyng2pmx0jfw5rkx4fjjl3u0zxz6nlyaja53p2n0ydupr6jsdnqt8q.nodns.shop AIn-Browser DNS Lookup
Resolve DNS records directly from your browser via Cloudflare DNS-over-HTTPS:
Architecture
In the future, a ccTLD operator could run their own nodns-bot to enable Nostr-native DNS for an entire country-code TLD.
Protocol Specification
Nostr kind 11111 events with structured tags for DNS records, delegation, payments, and registrar management.
Event Structure
{
"kind": 11111,
"pubkey": "<hex public key>",
"tags": [
["record", "TYPE", "name", "rdata", "", "", "", "", "", "", "ttl"],
["delegation", "DOMAIN", "NPUB", "VALID_FROM", "VALID_UNTIL", "RENEW_BY"],
["registrar", "ZONE", "PUBKEY_HEX"],
["cashu", "TOKEN", "MINT_URL", "AMOUNT"],
["zap", "ZAP_RECEIPT_EVENT_ID", "AMOUNT"]
],
"content": "",
"created_at": <unix timestamp>
}Tag Types
| Tag | Format | Description |
|---|---|---|
| record | ["record", TYPE, NAME, RDATA, "", "", "", "", "", "", TTL] | DNS record entry. 11-element fixed array for forward compatibility. |
| delegation | ["delegation", DOMAIN, NPUB, VALID_FROM, VALID_UNTIL, RENEW_BY] | Grants a pubkey control over a human-readable name within a zone. |
| registrar | ["registrar", ZONE, PUBKEY_HEX] | Identifies the registrar authority for a zone. Only this key can issue delegations. |
| cashu | ["cashu", TOKEN, MINT_URL, AMOUNT] | Anti-spam payment via Cashu ecash tokens (250 sats per new record). |
| zap | ["zap", ZAP_RECEIPT_EVENT_ID, AMOUNT] | Payment proof via NIP-57 zap receipts. |
Record Tag Fields (11-element)
| Index | Field | Description |
|---|---|---|
| 0 | record | Tag identifier (literal "record") |
| 1 | type | DNS record type (A, AAAA, CNAME, TXT, MX) |
| 2 | name | Subdomain name ("@" for root, or e.g. "www") |
| 3 | rdata | Record data (IP address, hostname, text content) |
| 4-9 | unused | Empty strings (legacy padding) |
| 10 | ttl | TTL in seconds (as string) |
FQDN Construction
{name}.{npub}.{zone}
Examples (full npub truncated for readability):
name="@" → npub1ykal2...pa3dl.nodns.shop
name="www" → www.npub1ykal2...pa3dl.nodns.shop
name="blog" → blog.npub1ykal2...pa3dl.nodns.shop
Delegated names:
Delegation assigns: alice.nodns.shop → npub1abc...xyz
User publishes: name="alice" → alice.nodns.shopDelegation & Custom Names
A zone registrar (identified by a registrar tag) can delegate a human-readable name to a specific Nostr pubkey. For example, the nodns.shop zone registrar can assign alice.nodns.shop to npub1abc...xyzfor a fixed time period. The delegation is signed by the registrar's private key and published as a Nostr event.
Once delegated, the user publishes standard record tags with name set to their delegated name. The bot verifies the delegation exists and is valid before pushing DNS records. Delegations are irrevocablewithin their validity period — the Nostr event is the authoritative proof.
Allowed Record Types
A
IPv4 address mapping. Points a domain to an IPv4 address.
AAAA
IPv6 address mapping. Points a domain to an IPv6 address.
CNAME
Canonical name. Aliases one domain to another.
TXT
Text records. Used for verification, SPF, DKIM, etc.
MX
Mail exchange. Specifies mail server for the domain.
Common Mistakes & FAQ
⚠ Why is my record showing up as a long nested domain?
If your record looks like this in the browser:
blog.alice.nodns.shop.npub13udukn...pgx.nodns.shopYou put a full domain path in the name field instead of a simple subdomain label.
The name field in a record tag should only be the subdomain part. The bot automatically appends .{your_npub}.{zone} to construct the full domain. Think of it like this:
You type in name | Bot builds | Correct? |
|---|---|---|
| @ | npub1abc...xyz.nodns.shop | ✓ Root domain |
| www | www.npub1abc...xyz.nodns.shop | ✓ Subdomain |
| blog | blog.npub1abc...xyz.nodns.shop | ✓ Subdomain |
| blog.alice.nodns.shop | blog.alice.nodns.shop.npub1abc...xyz.nodns.shop | ✗ Wrong! |
What happened: A user wanted to publish a subdomain record for their delegated name. They put a full domain path like blog.alice.nodns.shop in the name field, probably intending to create records under a delegated name. But the bot treated the entire string as a subdomain label and appended their own npub and zone on top.
How to fix it: Use just blog, api, or www as the name. If you have a delegated name (e.g. alice.nodns.shop), just use the name part that was delegated to you.
What should I put in the name field?
The name field is the subdomain label only. The full domain is constructed automatically as:
FQDN = {name}.{your_npub}.{zone}@or empty string — your root domain (npub1abc...xyz.nodns.shop)www— createswww.npub1abc...xyz.nodns.shopblog— createsblog.npub1abc...xyz.nodns.shop- Any single label without dots — treated as a subdomain
Never put a full domain, another npub, or a zone name in the name field. The bot handles zone and npub construction for you.
How do I get a human-readable domain like alice.nodns.shop?
Human-readable names require cryptographic delegation from a zone registrar. A registrar publishes a delegation tag assigning a name (like alice.nodns.shop) to your npub for a fixed period. Once delegated, you publish records with the delegated name in the namefield, and the bot verifies the delegation before creating DNS records. This is not yet available for public signup — watch the roadmap for updates.
Can I publish records for a different zone?
No. You can only publish records for zones that recognize your events. Each zone has its own nodns-bot instance subscribed to its registrar's events. Publishing to the nodns.shop bot only creates records under *.nodns.shop. To publish under a different zone, that zone needs its own bot infrastructure. In the future, ccTLD operators could run their own nodns-bot to enable Nostr-native DNS for entire country-code TLDs.
How long until my records are live?
Typically 3–5 seconds from publishing your Nostr event. The bot subscribes to relays in real-time, validates the event, and pushes changes via DDNS immediately. You can verify with dig @ns1.nodns.shop {your_npub}.nodns.shop A.
Roadmap
Infrastructure
nodns-bot
Rust daemon. Subscribes to Nostr relays, validates kind 11111 events, pushes to Knot DNS via DDNS.
Knot DNS
Authoritative nameserver. Zone: nodns.shop. DDNS updates via RFC 2136.
Relay Pool
relay.damus.io, nos.lol, nostr.wine, relay.ngit.dev, relay.tollgate.me. Events propagate across all relays.
SQLite
Local state store. DNS records, delegations, registrar keys, rate limiting per npub.