1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
Title: **DEP-0000: DNS**
Short Name: `0000-dns`
Type: Informative
Status: Draft (as of 2018-04-27)
Github PR: [PR#25](https://github.com/datprotocol/DEPs/pull/25)
Authors: Paul Frazee
# Summary
[summary]: #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
[motivation]: #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"](https://web.archive.org/web/20171013151452/https://github.com/beakerbrowser/beaker/wiki/Authenticated-Dat-URLs-and-HTTPS-to-Dat-Discovery)) has had prior usage in the Beaker Browser and Dat CLI. A followup proposal (the ["DNS TXT solution"](https://web.archive.org/web/20180427202745/https://github.com/beakerbrowser/beaker/wiki/Dat-DNS-TXT-records-with-optional-DNS-over-HTTPS)) was made recently, but has not yet been deployed. This DEP intends to unify these proposals formally.
# Usage Documentation
[usage-documentation]: #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](#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
[usage-dns-txt-record]: #usage-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
[usage-wellknown-dat]: #usage-wellknown-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-process]: #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"](#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
[security-and-privacy]: #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).
## DNS-over-HTTPS
[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:
- [Google](https://developers.google.com/speed/public-dns/docs/dns-over-https)
- [Cloudflare](https://developers.cloudflare.com/1.1.1.1/dns-over-https/json-format/)
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
[drawbacks]: #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
[alternatives]: #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
[changelog]: #changelog
- 2018-04-27: First complete draft submitted for review
- 2018-05-07: Add "Security and Privacy" section and rewrite DNS TXT record schema.
|
