From 30628878b0832f371cfe4d0ad1ed9f41461247df Mon Sep 17 00:00:00 2001 From: Daniel Aleksandersen Date: Mon, 18 Feb 2019 16:06:57 +0100 Subject: [PATCH 1/3] 0005-DNS: Cache names longer with confidence Web server and DNS may be hijacked and return the wrong Dat key. This new caching method allows for name resolution caching to grow linearly as confidence in the returned result increases over time. E.g. if a name was first resolved three days ago, it can be cached for up to six additional days if we're confident in the resolver result. After two weeks, the name can be cached for four weeks and so on. Domain owner still controls maximum caching time with TTL. Increases performance and privacy while making clients less susceptible to centralized/decentralized service disruptions (such as a DDoS or a server running out of memory.) Reduces dependency on servers. --- proposals/0005-dns.md | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/proposals/0005-dns.md b/proposals/0005-dns.md index eb147c5..c1a20d9 100644 --- a/proposals/0005-dns.md +++ b/proposals/0005-dns.md @@ -83,16 +83,16 @@ TTL={time in seconds} 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 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. + - Caache the record as described below. - 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. + - If the server responds with a well-formed file, cache the record as described below, and return the record value. + The DNS TXT record must match this schema: @@ -110,6 +110,30 @@ The `/.well-known/dat` file must match this schema: 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. +Name cache lookup process: + +Name cache entries has four qualifies: origin (domain name : port), Dat key, first seen timestamp, and expiration timestamp. Timestamps are in seconds since the Unix epoch. + +- Client must check if the origin is in the cache. + - If the origin is not in the cache, client must perform resolution for the origin using the method described above. + - If the domain doesn't resolve, the cache lookup returns a failed lookup. + - If the domain resolves, add the origin; Dat key; set the current time as first seen timestap, and set the expiration timestamp to exactly 30 minutes. + - If the origin is in the cache, client must check if the expiration timestamp is now or in the future. + - If it's now or in the future, return the cached Dat key. + - Clients may oppertunisticly asyncronously renew cached entries that are ten minutes or less from expiring. + - If it's in the past, the client must resolve the origin using the method described above. + - If the resolution fails due to a server error (HTTP status code 5XX) or connection time out, and the expiration time is less than one week ago, return the cached Dat key. + - If the resoluton fails for any other reason or the expiration time is more than one week ago, then the name record should be deleted from the cache and return a failed lookup. + - If the resolution succeeded then the client must compare the previously cached Dat key to the newly resolved Dat key. + - If the two keys differ, then the cached key is replaced; set the current time to the first seen timestamp, and set the expiration timestamp to exactly 30 minutes. + - If the two keys are identical, renew the cache expiration timestamp using the following criteria: + - First number: Subtract the first seen timestamp from the current time and multiply by two; add the resulting number to the current timestamp. Second number: add the resolved TTL to the current time. + - Client sets the expiration timestamp to the smaller of the two resulting numbers. + - Client should enforce a minimum expiration time of 30 minutes and a maximum of 6 months. + - Return the resolved Dat key. +- Client should remove expired entries 30 days after expiration. +- After six months, client may set the first seen timestamp to the beginning of the Unix epoch. + # Security and Privacy [security-and-privacy]: #security-and-privacy @@ -163,6 +187,7 @@ Whereas traditional DNS leaks name lookups to everyone on the network, DNS-over- # Changelog [changelog]: #changelog +- 2019-02-18: Increase resolution caching time linearly as cofidence in resolved result increases. - 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. From 84e6270eeaed6a3188c61c2cec7242adff003192 Mon Sep 17 00:00:00 2001 From: Daniel Aleksandersen Date: Mon, 18 Feb 2019 16:22:08 +0100 Subject: [PATCH 2/3] Encurrage long TTLs --- proposals/0005-dns.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/0005-dns.md b/proposals/0005-dns.md index c1a20d9..83e5a3c 100644 --- a/proposals/0005-dns.md +++ b/proposals/0005-dns.md @@ -65,6 +65,8 @@ The first option is to set a DNS TXT record at the domain which maps to a "key"- datkey={key} ``` +The minimum TTL is `1800` (30 minutes). TTL durations of weeks and months are encurraged to reduce the dependency on DNS unless you expect to change your Dat key. Start out with a short TTL and increase it over time. + ## .well-known/dat [usage-wellknown-dat]: #usage-wellknown-dat @@ -75,7 +77,7 @@ 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. +`TTL` is optional and will default to `1800` (30 minutes). This is also the minimum TTL. TTL durations of weeks and months are encurraged to reduce the dependency on your HTTPS Server unless you expect to change your Dat key. Start out with a short TTL and increase it over time. # Resolution process From cadd2651b7a5f20dcd3732527c3fab2db0278fa7 Mon Sep 17 00:00:00 2001 From: Daniel Aleksandersen Date: Mon, 18 Feb 2019 20:01:49 +0100 Subject: [PATCH 3/3] Simplify language and fix spelling Include example algorithm. --- proposals/0005-dns.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/proposals/0005-dns.md b/proposals/0005-dns.md index 83e5a3c..e223937 100644 --- a/proposals/0005-dns.md +++ b/proposals/0005-dns.md @@ -87,7 +87,7 @@ Resolution of a Dat at `dat://{name}` should follow this process: - 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): - - Caache the record as described below. + - Cache the record as described below. - 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. @@ -114,27 +114,29 @@ Note that DNS-record responses may not follow a pre-defined order. Therefore the Name cache lookup process: -Name cache entries has four qualifies: origin (domain name : port), Dat key, first seen timestamp, and expiration timestamp. Timestamps are in seconds since the Unix epoch. +Name cache entries have four qualifiers: origin (domain name : port), Dat key, first seen timestamp, and expiration timestamp. Timestamps are in seconds since the Unix epoch. - Client must check if the origin is in the cache. - If the origin is not in the cache, client must perform resolution for the origin using the method described above. - If the domain doesn't resolve, the cache lookup returns a failed lookup. - - If the domain resolves, add the origin; Dat key; set the current time as first seen timestap, and set the expiration timestamp to exactly 30 minutes. - - If the origin is in the cache, client must check if the expiration timestamp is now or in the future. + - If the domain resolves: cache the origin and Dat key; set the current time as first seen timestap, and set the expiration timestamp to exactly 30 minutes. + - If the origin is in the cache, the client must check the expiration timestamp. - If it's now or in the future, return the cached Dat key. - - Clients may oppertunisticly asyncronously renew cached entries that are ten minutes or less from expiring. + - Clients may opportunistically asyncronously renew cached entries that are ten minutes or less from expiring. - If it's in the past, the client must resolve the origin using the method described above. - - If the resolution fails due to a server error (HTTP status code 5XX) or connection time out, and the expiration time is less than one week ago, return the cached Dat key. + - If the resolution fails due to a server error (HTTP status code 5XX) or a connection time out, or the server is unreachable, and the expiration time is less than one week ago, return the cached Dat key. - If the resoluton fails for any other reason or the expiration time is more than one week ago, then the name record should be deleted from the cache and return a failed lookup. - If the resolution succeeded then the client must compare the previously cached Dat key to the newly resolved Dat key. - - If the two keys differ, then the cached key is replaced; set the current time to the first seen timestamp, and set the expiration timestamp to exactly 30 minutes. - - If the two keys are identical, renew the cache expiration timestamp using the following criteria: - - First number: Subtract the first seen timestamp from the current time and multiply by two; add the resulting number to the current timestamp. Second number: add the resolved TTL to the current time. - - Client sets the expiration timestamp to the smaller of the two resulting numbers. - - Client should enforce a minimum expiration time of 30 minutes and a maximum of 6 months. - - Return the resolved Dat key. + - If the two keys differ, then the cached key is replaced: set the current time to the first seen timestamp, and set the expiration timestamp to exactly 30 minutes. + - If the two keys are identical, renew the cache expiration timestamp using the following algorithm: + + `currentTime + max(30min, min(TTL, min(6months, (currentTime - firstSeen) * 2)))` + - Compare these two numbers and choose the smaller. First number: Subtract the first seen timestamp from the current time and multiply by two; add the resulting number to the current timestamp. Second number: add the resolved TTL to the current time. + - Adjust the number to be at least 30 minutes in the future and no more than 6 months. + - Set the resulting number as the new expiration timestamp. + - Return the resolved Dat key. - Client should remove expired entries 30 days after expiration. -- After six months, client may set the first seen timestamp to the beginning of the Unix epoch. +- Client may discard the first seen timestamp by setting it to 0 after six months. # Security and Privacy [security-and-privacy]: #security-and-privacy