Domain Key Service

Requirements

Sacrifice human readability of "name"s because:

No root name servers because:

Space of "name"s must be large so anybody can get one.

Registration of a "name" must be cheap, easy, automatable.

Each "name" is mapped to a record including:

Clients can look up the record (including the IP address) associated

with a "name":

Names are "owned" by the person who registered them.

The owner of a "name" can edit the data associated with the name.

Such edits must propagate across the internet in a timely fashion, similarly to DNS.

Running a name server should be cheap:

Design

A "name"s is (the one-way hash of) a public key.

The cryptographic identity of the owner is the (unhashed) public key.

The owner of a "name" is anybody who knows the corresponding private key.

The record associated with a name is a small text file in a defined format (S-expression? JSON?), signed with the private key.

A name server is a hashtable from names to records, hosted at a known IP address.

Queries can be submitted to any name server using a UDP-based protocol. It suffices to find just one that knows the corresponding record.

A non-hierarchical list of the IP addresses of well-known name servers is distributed with your OS.

Where name servers disagree, the most recent (past) registration date wins.

When a record expires, a replacement can be fetched from the authoritative name server using an ordinary query.

Name servers attract traffic by mirroring each other, thus propagating updates around the internet.

The best name servers can perhaps charge a small fee for registrations, which people will pay in order to provide low-latency authoritative responses to the widest audience.