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.
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.