Loading...
In the future, a ccTLD operator could run their own nodns-bot to enable Nostr-native DNS for an entire country-code TLD.
Rust daemon. Subscribes to Nostr relays, validates kind 11111 events, pushes to Knot DNS via DDNS.
Authoritative nameserver. Zone: nodns.shop. DDNS updates via RFC 2136.
relay.damus.io, nos.lol, nostr.wine, relay.ngit.dev, relay.tollgate.me. Events propagate across all relays.
Local state store. DNS records, delegations, registrar keys, rate limiting per npub.
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.
NoDNS will never create a token. Naming is a utility, not an investment.
Sats burned to miners (proof of work equivalent, no beneficiary)
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.
The 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
Tor onion addresses are derived from a public key. Nobody can take your .onion address because nobody can derive a different key that produces the same address. This is the closest existing analogy to $npub.nostr — your key IS your address. The difference: .onion addresses route traffic through the Tor network, while $npub.nostr resolves to DNS records. Both share the same core insight: cryptographic identity as naming.
Authority: Cryptographic (derived from public key, same as .nostr)
Pattern: {public_key_derived}.onion
Resolution: Tor client → .onion address → rendezvous with hidden service
The 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. The wire format (kind 11111 record tags) is zone-agnostic — the same event applies to .nostr, .nodns.shop, or any zone. Resolution is an infrastructure-layer concern, not a protocol-layer concern. Only $npub.nostr is supported — $string.nostr returns NXDOMAIN because there is no consensus mechanism for string ownership under .nostr.
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) or DoH endpoint → subscribes to Nostr relays → serves from cache
The 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. The same zone-agnostic events that create records under .nostr also create records here — no wire format changes needed.
Authority: Cryptographic (nsec/npub) + parent domain operator mirrors to standard DNS
Pattern: {npub}.{zone} → npub1ykal2...pa3dl.nodns.shop
Ref: Protocol experimental draft
Standard DNS query → zone's nameserver → recordsNostr relay subscription → event verification → recordsNostr 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.An 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
Standard DNS query → zone's nameserver → recordsNostr relay → delegation event + record events → verify signatures → recordsNostr events are the truth. DNS is a cache. If they disagree, DNS has been tampered with.A 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
A 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
A 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
Various 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. Included for comparison — NoDNS explicitly rejects this approach.
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
| Model | Who Decides | Token? | Censorship Resistance | Standard DNS? | Status |
|---|---|---|---|---|---|
| Traditional DNS | Registrar/ICANN | No | None | Yes | External |
| Tor .onion | Private Key (derived) | No | Absolute | No (Tor only) | External |
| $npub.nostr | Private Key | No | Absolute | Via DoH/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 |
| Crypto Naming (ENS etc.) | Smart Contract | Yes | High | No | External |
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.
Nostr kind 11111 events with structured tags for DNS records, delegation, payments, and registrar management.
{
"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 | 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. |
| 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) |
{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.shopA 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.
IPv4 address mapping. Points a domain to an IPv4 address.
IPv6 address mapping. Points a domain to an IPv6 address.
Canonical name. Aliases one domain to another.
Text records. Used for verification, SPF, DKIM, etc.
Mail exchange. Specifies mail server for the domain.