.lune DNS
Human-readable names resolving to Astrolune addresses, with ownership recorded on-chain rather than in a registrar's database.
Nothing is implemented, and nothing should be until the virtual machine, state and transaction layers exist. A naming service is a contract plus a resolver, and neither can be written without them.
Name lookup
Resolving against a local fixture set.
Records
- ADDR
- Address the name resolves to
- CONTENT
- Content hash
- TXT
- Free-form text records
- A / AAAA
- A / AAAA / TXT for conventional DNS interoperability
Open questions
The interesting questions here have been answered badly several times in public. These are recorded rather than guessed at.
Name allocation
First-come-first-served invites squatting; auctions price it but exclude; rent prevents permanent squatting on dead names but adds an expiry that must be timed off block height, never wall-clock time.
Reserved names
Whether trademarks, or names matching real DNS TLDs, are blocked. Every project that did not decide this early regretted it.
Resolution outside the chain
The genuinely hard part. A browser extension, a local DNS proxy, a DoH endpoint, or a gateway domain — the last of which reintroduces a central point and defeats the purpose. No decentralised naming system has solved this well.
Subdomains and delegation
Whether a name owner can issue subdomains, and whether those live on-chain or are delegated off it.
Surveillance surface
Resolution reveals what a user is looking up. DNS-over-HTTPS exists because plaintext DNS was a surveillance surface; a naming service is one too.
What must exist first
The VM, the state layer, the transaction layer, a working Trocto compiler, and a settled answer to whether a name is an account entry or an owned object. A name is the textbook example of a thing you want to be non-duplicable.