Subdomain Design and Implementation

This section is predominantly cribbed from this issue. The discussion there may be more active than the design doc here, but I will try to keep this up to date.

Subdomains will allow us to provide names to end users cheaply (and quickly).

Strong subdomain ownership

For those who are new to this concept, it's a model where domains can permanently, cryptographically delegate subdomains to particular keys, relinquishing their ability to revoke the names or change the name resolution details.

These names will be indicated with an ., e.g., foo.bar.id

Overall Design

We can do this today with a special indexer & resolver endpoint and without any changes to the core protocol.

We can do this by having a zone file record for each subdomain i containing the following information:

A public key PK
A sequence number N
A set of URLs
A signature S of the above

The signature S_i must be provided by the public key in the *(N-1)*th entry for subdomain i.

Zonefile Format

For now, the resolver will use an TXT record per subdomain to define this information. The entry name will be _subd.$(name), and the information will be comma-delimited:

$ORIGIN bar.id
$TTL 3600
pubkey TXT "pubkey:data:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
registrar URI 10 1 "bsreg://foo.com:8234"
_subd.foo TXT "pubkey:data:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,N:3,url:https://foobar.com/profile,url:https://dropbox.com/profile2,sig:data:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

The registrar entry indicates how to contact the registrar service for clients of the domain wishing to register or modify their entry.

Support for compression

As we will be packing more data into the zonefiles, 4K may become cumbersome. Compression can be explored in this case.

Domain Operator Endpoint

We'll need to provide an API endpoint for sending operations to the domain operator and an interface for sending commands to that endpoint.

Operating a domain should be something that anyone running a Core node should be able to do with a simple command:

$ blockstack domain foo.id start

Resolver Behavior

When a lookup like foo.bar.id hits the resolver, the resolver will need to:

Lookup the zonefile history of bar.id
Fetch all these zonefiles and filter by operations on foo
Verify that all foo operations are correct
Return the latest record for foo
Do a profile lookup for foo.bar.id by fetching the URLs in the entry. Note, this spec does not define a priority order for fetching those URLs.

Subdomain Caching

A resolver may cache a subdomain's state by keeping a database of all the current subdomain records.

3.0 KiB Raw Blame History