[dns-privacy] Trying to understand DNS resolver 'discovery'

[Phillip Hallam-Baker <[e-mail]>]

This notion of DNS resolver discovery seems very strange to me. There are
three ways in which a DNS resolver can be realistically determined by a
client whether that is in the platform (Windows/OSX/Linux/etc) or the
application.

1) Promiscuous DNS
    The client obtains the information to connect to a resolver either as
part of DHCP configuration or by further interrogation of the local network.

2) Admin/User Configured DNS
    The client obtains the information to connect to a resolver through an
Administrator or User configuration action. This may be inserting an IP
address (8.8.8.8/1.1.1.1/etc) or some form of DNS label.

3) Application/Platform Provider Configuration.
    The application or OS platform can simply ignore user preferences and
choose a DNS provider of its own liking.

This is not an exhaustive enumeration of the possibilities of course. But
please, assure me that we are not the brink of users being faced with pop
ups asking them 'would you like to choose me as your DNS provider'.


Of these three models, I have always considered (1) to be a security hole.
It made some sense in the days when the smallest machine connected to the
Internet was the size of a washing machine and portable computers didn't
exist. But not today.

[As a pragmatic matter, it will continue to be necessary for devices to use
the local network DNS resolver for the purpose of connecting to WiFi in
kiosk type environments. ]

We might well see the third model being imposed by government decree in
some places. Along with the DNSSEC root key to be used for validation.

Yes, there are situations where split DNS has to be considered so that the
device knows that when it is on the employer network it behaves
differently. But I see those as being a subset of VPN config. If Alice
works for example.com, then she can install a signed config file stating
which DNS resolvers and IPSEC (or other VPN) parameters to use on which
networks for which sets of DNS addresses.


So what I see is a requirement for DNS resolver configuration. We already
have rfc6763 to tell us how to get from a DNS label to an Internet service.
Albeit one that presupposes the existence of a resolution mechanism. I
don't see it being problematic to use the local DNS to do this resolution
provided that 1) we have the means to authenticate the connection and 2) we
only use this mechanism once, to perform initial configuration.

DNS resolution service providers do need to change their IP configs from
time to time of course. But there is an expectation that the resolver IP is
stable over very long periods of time. Moving to DNS names for resolvers
does not free us from this expectation in this case.

In my view, choice of a DNS resolver should be an event backed by ceremony
so while I think we can and should insist on DNSSEC authentication for the
resolver[1], there is certainly a potential role for a WebPKI certificate
to establish accountability (i.e. EV). There is also a potential role for
use of rfc3709 (logotypes) to provide a strong security signal during a
one-time configuration operation.

[1]  Even if the local resolver does not support DNSSEC or insists on the
use of an untrusted root, the DPRIV service being connected to can provide
this information as part of the initial handshake.