Title: DEP-0005: DNS

Short Name: 0005-dns

Type: Informative

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

Github PR: PR#25

Authors: Paul Frazee

Summary

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.

Motivation

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

Must provide a single canonical Dat URL for the domain. It should not be possible for a name to have multiple valid mappings. (No conflict.)
Must not be controllable by non-owners of the domain. It should not be possible for third parties to modify the mapping. (Secure.)
Should be accessible to as many users as possible. (Convenient.)

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":

^[0-9a-f]{64}$

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 fit the following schema:

datkey={key}

.well-known/dat

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:

dat://{key}
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:

Client checks its names cache. If a non-expired entry is found, return with the entry.
Client issues a DNS TXT request for name. This request should be issued via a secure transport (see "DNS-over-HTTPS").
Client iterates all TXT records given (skip if none). If a record's value matches the TXT record schema (see below):
- If the record includes a non-zero TTL, store the record value in the names cache.
- Return the record value.
Client issues an HTTPS GET request to https://{name}/.well-known/dat.
- If the server responds with a 404 Not Found status, client stores a null entry in the names cache with a TTL of 3600 and returns a failed lookup.
- If the server responds with anything other than a 200 OK status, return a failed lookup.
- If the server responds with a malformed file (see below), return a failed lookup.
- If the server responds with a well-formed file, store the record value in the names cache (default TTL to 3600 if not provided) and return the record value.

The DNS TXT record must match this 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.

Security and Privacy

Two issues to consider:

Security: Can we trust the lookup results for a name?
Privacy: Who sees the DNS lookups?

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.

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:

Security. Requests to the DNS provider are authenticated using the provider's SSL certificate.
Privacy. DNS lookups are encrypted on the wire and only made visible to the DNS provider.

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.

Drawbacks

The use of the .well-known/dat resource over HTTPS creates a dependency on a service.
DNS-over-HTTPS exposes all lookups to the provider and relies on the provider to be honest. However, because this method offsets the risk of MITM attacks, this is a worthwhile trade. Future DEPs should find alternative ways to authenticate domain-name records.

Rationale and alternatives

User-defined names registries could be used instead of DNS, but they would likely suffer from name conflicts without a top-down control.
A blockchain (such as Namecoin) could be used instead of DNS, but blockchains currently have poor throughput and require users to sync large amounts of data.
DNSSEC could be used instead of DNS-over-HTTPS, but it does not have the same level of support among gTLDs that DNS-over-HTTPS has.

Changelog

2018-04-27: First complete draft submitted for review
2018-05-07: Add "Security and Privacy" section and rewrite DNS TXT record schema.
2018-05-16: Merged as Draft after WG approval.

index.md 14KB Raw Blame History