Skip to content
This repository was archived by the owner on Dec 27, 2022. It is now read-only.

Dat DNS TXT records with optional DNS over HTTPS

Jump to bottom
Paul Frazee edited this page Apr 15, 2018 · 5 revisions

Beaker needs a mechanism by which users can securely deploy a site at a domain, eg dat://beakerbrowser.com. Ideally, this mechanism will allow discovery and automatic redirection; for instance, if the user browses to https://beakerbrowser.com, they should be prompted to redirect to dat://beakerbrowser.com.

Requirements

  1. MUST provide a single canonical Dat URL for the domain. It should not be possible for multiple Dats to be specified within a domain. This means the Dat must be specified by a single fixed file, or by DNS.
  2. MUST not be controllable by non-owners of the domain. It should not be possible for user-input or injections to set the Dat URL.
  3. MUST cryptographically authenticate the validity of the entry.
  4. SHOULD be accessible to as many users as possible (eg response headers are frequently unsettable).

History

Previously we have used the Authenticated Dat URLs and HTTPS to Dat Discovery spec (aka the ".well-known" solution). The .well-known solution was chosen because Dat does not currently have the support of SSL certificates to verify ownership. Without verification, the DNS lookup could be intercepted by an adversary on the network and modified.

The .well-known solution suffers from some downsides:

  1. An HTTPS host must be run for each Dat to provide the domain name. This adds a lot of overhead to users (and ruins some of the fun of p2p).
  2. If the HTTPS host is run on behalf of the user, there is the potential for the host operator to modify the mapping.
  3. It isn't the direction we intend to go with Dat domain names in the long term, and so it won't transition smoothly in the future.
  4. Operators of pinning services would need users to point their domain's A records to the pinning service's IP. Because the users' domain records are not under the pinning service's control, it becomes very difficult to change the IP in the future.

These problems have motivated us to look for an alternative.

Proposal

Create a DNS TXT record with the following value:

dat://{raw-url}/

This record must match the following regexp:

^dat:\/\/[0-9a-f]{64}\/?$

Dat-name Resolution

Resolution of a site at dat://hostname will occur with the following process:

  • Browser checks its dat names cache. If a non-expired entry is found, return with the entry.
  • Browser issues a DNS TXT lookup for hostname.
  • Iterate all TXT records. If a record matches the regex above:
    • If the record includes a non-zero TTL, store the entry in the dat-name cache.
    • Return the entry.
  • If no matching records is found, attempt the .well-known lookup.

Optional 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 can use DNS-over-HTTPS to lookup the DNS TXT records.

Possible providers:

The downside of this approach is that it exposes all lookups to the provider, and relies on the provider to be honest. The positive is that the users simply use DNS records, and do not need to worry about MITM attacks.

Because the risk of an adversary is high, the Beaker team recommends using DNS-over-HTTPS.

Discovery

Visits to sites served over HTTPS should trigger Dat-name Resolution. If an entry is found, the browser UI will present the user with an option to redirect to the Dat site. Discovery traffic will be throttled by the Dat-name caching.

Clone this wiki locally