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 protected]> wrote:
> 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
>
> --
> Add mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/add
>
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
