Subject: [dns-privacy] Draft on the use of multiple recursive resolvers

From: Jari Arkko <[email-masked]>
Date: Sat, 16 Nov 2019 15:38:27 +0800

I wanted to point people to a draft that Martin, Ted, and me recently submitted
on the use of multiple resolvers. This is early work; comments and additional
analysis appreciated.

https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00

   This memo discusses the use of a set of different DNS resolvers to
   reduce privacy problems related to resolvers learning the Internet
   usage patterns of their clients.

Jari

---

From: Vittorio Bertola <[email-masked]>
Date: Sun, 17 Nov 2019 07:30:47 +0100 (CET)

> Il 16 novembre 2019 08:38 Jari Arkko <[email-masked]> ha scritto:
> 
>  

Well, as you recognize in the draft itself, this is just "a narrow aspect within a bigger set of topics", so I would find it more useful to start from the broader discussion, the one you hint at in the final part of the draft: is there a reason to change the current model that has been generally adopted until now, i.e. the user picks (or is supplied) a resolver and all the queries go through it? What are the advantages and disadvantages of spreading the queries instead of using a single resolver?

Even in terms of privacy, I would not be so sure that spreading the queries to multiple parties could ever provide more privacy than sending them only to a single trusted party, even if we could actually come up with a distribution strategy that solved the problem of letting all resolvers see most of your traffic over time. The original point of contention in this discussion was the browser sending the queries to a different resolver than the one they were meant for - not the fact that a single resolver was being used. Also, the entire legal data protection architecture in Europe relies on the fact that the user knows and authorizes each single party that gets a share of their data, which is philosophically the exact opposite of a model in which data start to be sent here and there in ways that the user is unable to control.

Moreover, you cannot discuss these alternatives only in regard to privacy, as the choice will affect many other dimensions. By choosing a specific resolver, users can get better performance or additional services - how could this work if their queries started to be distributed? ISPs use their resolvers as a network security platform and as a way to make their Internet access service faster than competitors; it is unclear why they should spend considerable money to provide big scale resolvers if these resolvers will not be part of their service any more, and will rather be used at random by random users every now and then (so you would, again, reduce the number of mainstream resolver providers to the few usual suspects that can afford the cost no matter what). Then there's all the lawful interception and content blocking part, which people here tend to dismiss, but governments won't. So I am afraid that if you only discuss a single part of the problem, you will end up worsening the ot
 hers and not solving much.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Brian Dickson <[email-masked]>
Date: Sun, 17 Nov 2019 19:09:31 +0800

I scanned it briefly, and have a question about whether it makes sense to
consider a couple of syntactic/semantic additions.

I believe there would be more value to support explicit ordering as well as
randomization within a given set at the same level of preference.
I also believe adding rules for fallback to non-private servers would be
advisable, even if some configurations choose to exclude the fallback
server set.

(Whether this uses names with hints for corresponding IP addresses of
servers, or not, is another question; that might better be addressed
separately?)

Using bind-style syntax, I would imagine something like:

resolvers {
 policy round-robin;
 fallback timeout 2s;
 set 1 {
   pref 30;
   proto dot;
   servers { 9.9.9.9; 8.8.8.8; 1.1.1.1;}
    }
 set 2 {
   pref 20;
   proto doh;
   servers {9.9.9.9; 8.8.8.8;}
   }
 set 3 {
  pref 10;
  proto dns;
  servers {1.1.1.1;}
  }
}

The concept would be to list the preferred sets of servers/protocols and
their respective preference levels, along with resolver selection policy
(possibilities could be best, round-robin, random-order, etc).
Fallback to lower-preference sets would be controlled by fallback policy.

The idea is to avoid privacy-impacting server/protocol selection generally
(resistant to downgrade attacks), if the client so desires.

Everything else in the draft would generally be applicable to the selection
policy within server sets.

This is a richer semantic than the traditional /etc/resolv.conf, but the
latter doesn't really support anything other than traditional port 53, so
being restricted by the old semantics seems unwise.

Brian

On Sat, Nov 16, 2019 at 3:38 PM Jari Arkko <[email-masked]> wrote:

> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 18 Nov 2019 14:32:59 +0100

> https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00

A colleague implemented the PSL approach for Knot Resolver recently
where user picks the resolver set, but I'm skeptical about
spreading-with-PSL significantly improving privacy.  Still, it was less
than one screen of code (+PSL dependency) some people have asked for
this, so why not.

Trusting one provider seems better to me (or two... for a fallback).  If
you can't trust any, you probably need a Tor-like approach to separate
your address from your queries.

(For now I'm leaving non-DNS leaks aside, e.g. SNI, sets of IPs usually
determining the name uniquely, etc.  For now I'd go for a full VPN if
you trust a provider or Tor if you don't.)

Client-based splitting seems to be a worsening (!)  as one of privacy
benefits is precisely the inter-mingling of queries from multiple
clients and thus reduced ability to track the individuals.

--Vladimir

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 18 Nov 2019 14:35:39 +0100

On 11/18/19 2:32 PM, Vladimír Čunát wrote:
> where user picks the resolver set

I forgot the link:
https://knot-resolver.readthedocs.io/en/stable/modules.html#c.policy.slice

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Nov 2019 06:51:42 +0800

Brian,

Thanks for your comments.

> Using bind-style syntax, I would imagine something like:

Something like this would definitely be useful. It is important to observe though that there are interactions with the ability to keep things private and excessive round-robining/going-to-alternate. The second bullet in Section 3 talks about this in the draft. With that caveat, having an expressive way to define which resolvers you want to talk to is much needed.

Jari