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

[Brian Dickson <[e-mail]>]

On Tue, Nov 26, 2019 at 9:35 AM Phillip Hallam-Baker <[e-mail]>
wrote:

> This notion of DNS resolver discovery seems very strange to me.
>

The larger issue (and the one I am interested in finding solutions for) is
that what is configured as a 'resolver', might actually be a 'forwarder'.

I.e. the path is generalized as client -> forwarder* -> resolver (zero or
more forwarders).

Any DNS client, and any DNS server, when communicating, are unable to
distinguish whether the other is (respectively) a resolver or forwarder, or
a client or forwarder.

For the DPRIVE use case, it is hopefully clear that the path from the
client to the (ultimate) resolver, needs to be encrypted in order to
achieve privacy.

However, if the only place the client is able to establish an encrypted
path to is a forwarder, this leave open the possibility that the
forwarder->(forwarder->[...])->resolver might involve one or more
unencrypted connections.

Depending on the network(s) and presence of NAT(s), it may or may not be
possible for the client to communicate directly with the (ultimate, actual)
resolver.

It is also a potential issue in addressing this issue with any
mechanism(s), that intermediate forwarders and the resolver itself, may not
have FQDNs of any sort, may not have NSIDs configured, and may not have
public (globally unique) IP addresses.

So, the 'discovery' can involve any or all of, some naming method (for
things without FQDNs), path discovery, address discovery, and address scope
conflict detection, with the preferred result of client->resolver direct
connection with encrypted transport.

Brian