Subject: [Add] 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: Paul Ebersman <[email-masked]>
Date: Mon, 18 Nov 2019 04:58:13 +0800

bdickson> I believe there would be more value to support explicit
bdickson> ordering as well as randomization within a given set at the
bdickson> same level of preference.

That ship sailed years ago. Round robin as load balancing (or any use of
expected order of RRs in an RRSet) is never going to be reliable. If you
have some need for it, do it in the code doing the DNS queury or you
will be surprised.

This is from painful years of tech support of BIND explaining why this
wasn't doing what someone wanted. There are too many stub and recursive
resolvers out there we can't change that won't "behave".

What use case do you think this solves?

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 10:30:36 +0800

> What use case do you think this solves?

I was responding in the context of the draft by Jari, which supposed
privacy improvement by this sort of round robin from clients to resolvers.

In retrospect, I think you're right, it makes much more sense to stick to a
single resolver.

That said, my suggestion is probably moderately useful for the more
explicit selection of such a single resolver, as well as providing an
"electric fence" to optionally protect against downgrade from private to
non-private.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 18 Nov 2019 10:51:45 +0800

Hi Brian

> privacy improvement by this sort of round robin from clients to resolvers.
In the author discussion, we were each convinced that a basic round-robin
of queries to a set of resolvers ended up leaking the most of any of the
strategies, because there were many conditions (common web pages or apps)
in which all of the resolvers ended up with enough information to identify
which web pages/resources the client was attempting to access.

My apologies that this didn't get communicated in the draft well; we'll try
to make it clearer in later versions.

regards,

Ted

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 18 Nov 2019 11:03:47 +0800

On Mon, Nov 18, 2019, at 10:51, Ted Hardie wrote:
> My apologies that this didn't get communicated in the draft well; we'll 
> try to make it clearer in later versions.

Section 5.3 is entitled "Poor distribution strategies", but I realize that the text never outright tees up the idea that these are ideas that are explicitly bad.  You have to read more closely to get that.
https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00#section-5.3

---

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