Dat Protocol

DEP-0005: DNS

Title: DEP-0005: DNS

Short Name: 0005-dns

Type: Informative

Status: Draft (as of 2018-04-27)

Github PR: PR#25

Authors: Paul Frazee


Dat's data structures (HyperCore, HyperDB, and HyperDrive) are addressed using cryptographic keys. In the context of Web browsers, a URL scheme is used which is structured as 'dat://' {key} '/' {path...}.

This DEP describes an additional protocol for addressing Dats using DNS short names.


The cryptographic keys which address Dats are secure and global, but not human-readable. This creates a usability problem.

The goal of this DEP is to leverage DNS to provide human-readable shortnames which map to Dat's cryptographic addresses. The solution...

An initial proposal (the ".well-known solution") has had prior usage in the Beaker Browser and Dat CLI. A followup proposal (the "DNS TXT solution") was made recently, but has not yet been deployed. This DEP intends to unify these proposals formally.

Usage Documentation

Users may provide a Dat URL to clients with the following structure: 'dat://' {name} '/'.

If the name is a 64-character hex string, it should be considered a "key" and no DNS-resolution should occur. If name matches the following RegExp, it is considered a "key":


If the name does not match this RegExp, it is a "domain name" and requires resolution. A Dat client should follow the resolution process to do this.

domain: dat://beakerbrowser.com/
key:    dat://87ed2e3b160f261a032af03921a3bd09227d0a4cde73466c17114816cae43336/

Users have multiple options for creating a domain-name mapping.

DNS TXT record

The first option is to set a DNS TXT record at the domain which maps to a "key"-addressed Dat URL. The client will lookup this TXT record first and load the resulting Dat. That record should contain the following schema:


The above schema does not have to start of the TXT record, it just has to match somewhere in the TXT record. The 'key' must be a 64-character hex string.


The second option is to run an HTTPS server at the domain name which includes a /.well-known/dat resource. That resource should provide a text file with the following schema:

TTL={time in seconds}

TTL is optional and will default to 3600 (one hour). If set to 0, the entry is not cached.

Resolution process

Resolution of a Dat at dat://{name} should follow this process:

The DNS TXT record must contain the following schema:

'datkey=' [0-9a-f]{64}

The /.well-known/dat file must match this schema:

'dat://' [0-9a-f]{64} '/'?
( 'TTL=' [0-9]* )?

Note that DNS-record responses may not follow a pre-defined order. Therefore the results of a lookup may be undefined if multiple TXT records exist. Also the DNS TXT record entry does not have to start the record, it just has to match somewhere in the TXT record.

Security and Privacy

Two issues to consider:

Traditional DNS provides neither security or privacy. All looks occur over plaintext UDP. To provide security, a separate system must authenticate the record. (In the case of HTTPS records, the SSL Certificate provides authentication.)

Dat does not currently have a DNS authentication record (no equivalent to the SSL certificate). Therefore a lookup using UDP can not be secured.

To solve this, this DEP recommends using DNS-over-HTTPS.


Until PKI can authenticate the DNS lookups (ie via SSL certificates or equivalent) there is a risk that the DNS lookup will be intercepted by an adversary. To protect against this, the client should use DNS-over-HTTPS to lookup the DNS TXT records.

Current providers:

This solution improves on both the security and privacy of DNS lookup:

DNS-over-HTTPS still requires trust in the provider to give correct responses, but this is an improvement to UDP DNS lookups, which can be trivially MITMed by malicious actors on the network.

Whereas traditional DNS leaks name lookups to everyone on the network, DNS-over-HTTPS only reveals them to the DNS provider. This still provides some opportunity for tracking, but the opportunity is reduced to the provider alone.


Rationale and alternatives